Базовые компоненты JE
2.2.1.1. Документы клиента
Один из основных элементов Web-системы – это документы, которыми обмениваются клиент и сервер. На начальном уровне это означает Web-страницы (HTML). Тем не менее появление беспроводных устройств, которые поддерживают другие языки разметки, означает, что формат документа ни в коем случае не ограничивается HTML. Использование таблицы стилей для обработки клиентом или оконечным устройством означает, что документом клиента для сервера Web-приложений может быть и XML-документ.
2.2.1.2. JavaBeans
JavaBeans – это идеальный инструмент для создания многократно используемых компонентов Web-яруса, которые могут быть задействованы в связке с JSP. Они могут быть использованы для извлечения данных из JSPs или как средство связи между сервлетом и постпроцессором JSP. JavaBeans позволяет специфицировать линию поведения в файле характеристик вне Bean-логики. Это дает возможность разработчикам, использующим инструментарий разработки приложений (application development – AD), менять линию поведения Bean-компонента как части общего приложения.
2.2.1.3. Апплеты
Эти загружаемые Java-приложения подвергаются обработке в среде браузера виртуальной машины Java (Java Virtual Machine – JVM). Апплеты – это мини-приложения, которые загружаются в браузер и исполняются. Они позволяют создавать машинонезависимые функциональные возможности клиентского приложения, которые увеличивают возможности пользователя. Интерфейс апплета ограничен, предотвращая, таким образом, нежелательное разрушение системы, вызванное загрузкой апплета. Апплеты не имеют доступа к системным ресурсам клиента, что предотвращает вирусоподобное повреждение компьютеров.
2.2.1.4. Сервлеты
Компонент сервлет – это Java-эквивалент унаследованного интерфейса CGI. Идентифицированный в URL, конкретный сервлет принимает входящий Web-запрос. Сервлет обрабатывает входящий запрос, возможно взаимодействуя с J2EE EJB-компонентами или СУРБД, через JDBC, затем возвращает результаты в формате HTML запросившему клиенту. Сервлет имеет доступ к HTTP-запросу и сессии пользователя, через объекты Java, подготовленные вызовом. Сервлеты могут запускаться усовершенствованными способами. Например, сервлет перенаправления, или сервлет связывания, позволяет связывать многочисленные сервлеты для обработки единичного запроса пользователя. Несмотря на то, что сервлеты могут создавать HTML напрямую, практика диктует возвращение к JavaBean, который может быть использован JSP для подготовки документа, сцепляясь, таким образом, с шаблонами контроллера вида модели.
Сервлеты создаются, по мере надобности, контейнером сервлетов и остаются обслуживать многочисленные запросы от любого клиента. Когда сервлет запускается первый раз, срабатывает метод инициализации сервлетов, чтобы выполнить все инициализации, требующиеся при запуске. Для первой и всех последующих активизаций сервлетов запускается метод doGet (или метод doPost).
2.2.1.5. Серверные страницы Java (JavaSewer Pages)
Серверные страницы Java (JSP) образуют мост между управлением содержимым HTML и вызовом компонента Java. Разработчики JSP могут вставлять коды HTML и Java в JSP, чтобы добавить динамические функциональные возможности
2.2.1.6. Enterprise JavaBeans
Про Enterprise JavaBeans (EJB) часто думают, что это JavaBeans на стероидах. Несмотря на то, что эта концепция передает мощные функциональные возможности структуры EJB, EJB – это полностью отличающиеся от JavaBeans «животные». EJB обеспечивают структуру для построения усовершенствованных прикладных программ для деловой сферы со сложными компонентами (см. рис. 2.2). Инфраструктура EJB обеспечивает среду, в которой могут быть развернуты компоненты, могут быть использованы сервисы: распределенные транзакции, безопасность и управление жизненным циклом. EJB – это ответ Java на традиционные бизнес-подсистемы, такие, как IBM CICS и IBM IMS.
EJBs имеют три разновидности: сессионные Bean-компоненты (session beans), которые подвергают обработке бизнес-логику и могут быть использованы для управления технологическим процессом обработки; стабильные Bean-компоненты (entity beans), которые инкапсулируют данные, используемые бизнес-логикой; управляемые сообщением Bean-компоненты (message-driven beans), которые подвергают обработке управляемую событиями программную модель. Рассмотрим простой пример – банковское приложение, которое переводит средства с одного счета на другой. Стабильные Bean-компоненты могут использоваться для управления хранилищем данных, содержащим информацию о счете, тогда как сессионные Bean-компоненты позволяют бизнес-логике выполнить транзакцию дебетования одного счета и кредитования другого.
Сессионные Bean- компоненты могут быть либо имеющими состояние (stateful), либо не имеющими состояния (stateless). Имеющие состояние сессионные Bean-компоненты не помнят ничего из предыдущих вызовов (например, URL-запросов). Они оперируют информацией о среде клиента, возвращенной через cookies в браузере, в виде порожденного сервлетом сессионного объекта. Имеющие состояние сессионные Bean-компоненты могут запоминать среду клиента в течение сессии пользователя, но это имеет свою цену. Имеющий состояние сессионный Bean-компонент назначен для одного пользователя в течение сессии пользователя.
Стабильные Bean-компоненты обеспечивают инкапсуляцию данных. Подобно сессионным Bean-компонентам, стабильные Bean-компоненты также имеют две разновидности: с живучестью, управляемой контейнером (container-managed persistence – CMP), и с живучестью, управляемой Bean-компонентом (bean-managed persistence – BMP). В большинстве случаев СМР используется, чтобы инструктировать сервер Web-приложений о порядке управления, хранения и извлечения данных из базы данных. Это освобождает разработчика Bean-компонентов от беспокойства по поводу представления данных и их обработки, дает возможность заниматься интерфейсами баз данных и управлением транзакциями. Тем не менее BMP, которые отдают управление взаимодействием с базой данных в руки разработчика Bean-компонентов, требуются, когда структура данных нетиповая.
В вычислительной архитектуре EJB сервер J2EE управляет одним или несколькими контейнерами. Контейнеры EJB обеспечивают сервисы комплекту экземпляров Bean-компонентов Enterprise. EJB-контейнер отвечает за жизненный цикл EJB, доступ пользователя к EJB-ресурсам, живучесть, через СМР, и за вызов удаленного клиента. Контейнеры прозрачны для клиентских программ. Контейнер заботится об обеспечении уровня запрошенного сервиса во время развертывания, выступая посредником для каждого доступа к EJB. Например, он запускает транзакцию перед вызовом метода, если вы указали в дескрипторе развертывания, что этот метод должен выполняться в контексте транзакции.
Каждый экземпляр EJB должен иметь уникальный идентификатор. Идентификация сессионных Bean-компонентов не предназначена для общего пользования. Объекты создаются и ассоциируются с конкретными клиентами, но их существование без взаимосвязи с клиентом несущественно. Стабильные Bean-компоненты используются совместно и поэтому должны иметь явное местоположение. Возьмем пример операции обновления учетной записи. Сессионный Bean-компонент реализует операцию учетной записи, где стабильный Bean-компонент представляет учетную запись. Если оба, работодатель и служащий, пытаются обновить учетную запись в одно и то же время, в этом случае могут существовать два сессионных Bean-компонента, представляющие сессии работодателя и служащего, но только один стабильный Bean-компонент представляет учетную запись. Стабильный Bean-компонент делает единственный выбор основного ключа для доступа к объекту стабильного Bean-компонента и поддерживает этот основной ключ в домашнем интерфейсе.
Клиент использует домашний интерфейс для обнаружения, создания и удаленного запуска копий EJB (см. рис. 2.3). Каждая копия EJB содержит домашний интерфейс, который вместе со службой имен позволяет клиентскому приложению обнаружить отдельный экземпляр EJB. Когда новый EJB развернут, контейнер EJB регистрирует его подпись в службе имен. Используя интерфейс службы имен и каталогов Java (Java Naming and Directory Interface -JNDI), клиентская программа определяет местонахождение этого домашнего интерфейса. J2EE – это распределенная среда программирования, это означает, что домашний интерфейс может находиться в любом месте домена J2EE. После обнаружения домашнего интерфейса клиент активизирует метод поиска в EJB для обнаружения экземпляра EJB. Если экземпляр существует, то возвращается ссылка на него. Если он еще не существует, то сначала он создается, затем возвращается объектная ссылка. Контейнер отвечает за создание объекта – это часть поискового процесса домашнего интерфейса.
Интерфейс поиска может иметь многочисленные сигнатуры для размещения объекта. Например, вы можете найти учетную запись объекта клиента как ACCOUNTID или как комбинацию полей клиента NAME и HOME_TELEPHONE_NUMBER (если он забудет номер учетной записи).
Чтобы этого достичь, разработчик Bean-компонентов реализует многочисленные методы ejbFind(), с различной сигнатурой для каждого. Контейнер обрабатывает вызов корректного метода ejbFind(), основываясь на параметрах, полученных от вызывающего клиента. Контейнер и Bean-компонент работают в союзе для поддержки интерфейса поиска. Код Bean-компонента запускается из контейнера для определения места расположения экземпляра.
Контейнер поддерживает жизненный цикл каждого EJB. Он реализует производственный интерфейс для каждого класса Bean-компонента, созданного методами createQ, для различных сигнатур активизации объекта. Жизненный цикл также включает инициируемый клиентом вызов removeQ, чтобы удалить этот экземпляр. Так как EJB могут хранить важные ресурсы, есть два других метода жизненного цикла – ejbPassivateQ и ejbActivateQ. Это позволяет контейнеру уведомлять Bean-компонент о завершении жизненного цикла и, таким образом, освобождать ресурсы.
J2EE обеспечивает распределенную среду транзакций. Эта среда позволяет транзакциям координировать обновления многочисленных объектов EJB на многочисленных серверах J2EE, взаимодействуя с менеджерами различных ресурсов (например, баз данных). Преимущество использования EJB над другими методами обработки транзакций в том, что управление транзакциями не привязано жестко к приложениям. Он может быть сконфигурирован во время развертывания через дескрипторы развертывания.
Контейнер управляет контекстом транзакции, основываясь на ценности атрибута транзакции. Каждый EJB будет иметь одну из следующих установок транзакции либо для целого Bean-компонента, либо для конкретных методов:
• TX_NOT_SUPPORTED – нет транзакции поддерживающей вызов;
• TX_BEAN_MANAGED – разграничение транзакции обрабатывается Bean-компонентом;
• TXREQUIRED – этот EJB требует, чтобы всегда применялись управляемые контейнером транзакции;
• TX_SUPPORTS – этот Bean-компонент может запускаться любым способом;
• TX_REQUIRES NEW – этот EJB должен запускаться с новым контекстом транзакции;
• TX_MANDATORY – эта установка подобна TX_REQUIRED, за исключением того, что если клиент не имеет контекста транзакции, то новый контекст не создается, а выдаются сведения об ошибке.
Разграничение транзакции индицирует границы транзакции для стадий двухфазной фиксации: начало, подготовка, фиксация и откат. Имеются два метода для этой обработки. Первый метод – это когда клиент (который может быть сервлетом или EJB, активизированным другим EJB) может явно устанавливать разграничение. Контейнер понимает это разграничение, и если здесь нет конфликта с атрибутами транзакции участвующих EJB, то он проводит двухфазную фиксацию, как инициировано клиентом. Второй метод использует контейнер, который управляет разграничением. Клиент свободно запускает EJB-методы, не заботясь об инициации транзакций. Основываясь на дескрипторах развертывания, контейнер обнаружит, когда потребуется новый бизнес-контекст транзакции, и определит область действия контекста транзакции среди участвующих ресурсов.
• характеристики Bean-компонента (Bean characteristics) – имя Bean-компонента, класс, домашний интерфейс, удаленный интерфейс и тип (объект или сессия);
• класс «первичный ключ» (Primary key class) – идентифицирует класс «первичный ключ» для Bean-компонента;
• управление живучестью (Persistence management) – показывает, чем управляется живучесть: либо Bean-компонентом, либо контейнером;
• управляемые контейнером поля (Container-managed fields) – постоянные поля в классе Bean-компонента, которые контейнер должен синхронизировать с полями в соответствующем источнике данных, для проверки, что эти данные стабильны (persistent) и совместимы (consistent);
• реентерабельность (Reentrance – повторное использование) – определяет, может ли EJB активизировать методы сам, или он должен запросить другой Bean-компонент, чтобы активизировать метод; только стабильные Bean-компоненты можно использовать повторно;
• управление состоянием (State management) – определяет диалоговое состояние сессионного Bean-компонента; этот атрибут должен быть установлен либо на STATEFUL (имеющий состояние), либо STATELESS (не имеющий состояния);
• время ожидания (Timeout) – определяет значение времени ожидания в секундах, ассоциированное с этим сессионным Bean-компонентом.
Дескриптор развертывания содержит следующую информацию по сборке приложения:
• имя дисплея и иконки (Display name and icons) – идентифицируют модуль;
расположение файлов классов (Location of class files) – это обеспечивает клиентской программе доступ к Bean-компонентам в модуле;
• роли в системе безопасности (Security roles) – определяют логическое группирование процессов и пользователей; доступ к операциям (таким, как EJB-методы) контролируется с учетом ролевого имени;
• уровень прав для методов (Method permissions) – определяет соответствие между ролями в системе безопасности и методами, дозволенными для доступа пользователям с этими ролевыми именами;
•транзакция (Transaction) – определяет способ транзакции, в которой контейнер активизирует метод для Enterprise Bean-компонентов, что требует управляемого контейнером разграничения транзакции;
• уровень изоляции транзакции (Transaction isolation level) – определяет степень изоляции транзакций между собой, осуществляемую контейнером;
• RunAsMode/RunAsIdentity – определяет идентичность, используемую для запуска метода.
J2EE предлагает мощный набор сервисов, которые могут использоваться для построения многоярусных приложений Enterprise. Эти сервисы выходят далеко за пределы простой возможности применения баз данных в Web, обеспечивая безопасную, устойчивую инфраструктуру для компонентов и собираемых приложений.
DBExtenders (расширители DB
DB2 имеет несколько добавлений к реляционной модификации, которые в целом образуют расширители DB2 Extenders. Часто, используя большие символьные объекты (CLOB – character large objects) и большие двоичные объекты (BLOB – binary large objects), можно сохранять и обрабатывать в DB2 сложные текстовые структуры и изображения. Два из этих расширителей – DB2 XML Extender и DB2 Spatial Extender (Spatial – пространственный) для географических данных – подробно проанализированы в шестой главе. Расширители DB2 Audio/Video Interleaved (AVI) Extenders могут быть использованы для сохранения и извлечения сложных данных, ассоциированных с аудио, видео и изображениями. Также имеются другие расширители, включая поисковый DB2 Net Search Extender, DB2 Text Extender, DB2 Text Information Extender, которые обеспечивают схожие, но с некоторыми отличиями, функции для текстовых данных.
DB2 Net Search Extender имеет хранимую процедуру, которая может быть добавлена к приложениям Java и DB2 Call Level Interface. Она способствует быстрому полнотекстовому поиску и предварительной сортировке в памяти, чтобы уменьшить загрузку базы данных в память. DB2 Text Information Extender – это лучший выбор для приложений, где требуется использование SQL и важна автоматическая синхронизация текстовых индексов. Наконец, в приложениях, в которых необходима мощная лингвистическая поддержка, рекомендуется DB2 Text Search Extender. Он использует SQL для обеспечения полнотекстового и лингвистического поиска, основанного на словарях, фильтрации стоп-слов (stop word – часто встречающееся слово, не включаемое в поисковые индексы браузеров, например, определенный или неопределенный артикль) и поддержке синонимов ряда языков, включая английский, немецкий и японский.
Индустриальная мощность
Так как DB2 является центральной частью в нашем интегрированном решении, естественная тенденция – тщательно рассмотреть каждую ее возможность и функцию. При написании этой главы мы упорно сопротивлялись этому естественному стремлению. Имеется много источников информации этого типа. Перечисление их здесь заняло бы больше места, чем позволяет объем главы. Вместо этого рассмотрим основные параметры лучшей среди аналогов системы баз данных для интегрированных бизнес-решений. Мы приняли во внимание много факторов. После долгих раздумий мы остановились на трех основных необходимых качествах, которые могут быть использованы как критерий в оценке DB2 и других технологий баз данных:
• индустриальная мощность;
• взаимосвязь с приложениями Oracle Enterprise Manager (OEM) и интеграция с приложениями;
• способность к интеграции.
В этой главе мы исследуем эти ключевые особенности и объясним в основном, почему выбрана DB2. С точки зрения разработчиков и конструкторов, любая система баз данных должна иметь все три возможности, как показано на рис. 1.1. Эти факторы вступают в игру снова и снова при разработке и реализации интегрированных бизнес-решений, которые в большой степени зависят от технологии баз данных.
Под индустриальной мощностью мы подразумеваем больше чем сохранение и извлечение данных. Это взаимодействие надежности, масштабируемости, работоспособности и мобильности определяет функциональные возможности ядра системы баз данных. Проверка лакмусом индустриальной мощности – это подтверждение способности работы на многих платформах и операционных системах, что требуется во многих интегрированных решениях.
Например, DB2 имеет усовершенствованные технологии кеширования и буферизации, которые позволяют масштабирование и использование на многочисленных платформах.
Также индустриальная мощность, с нашей точки зрения, означает экономически эффективное предоставление надежности, масштабируемости, мобильности и т.п. Экономическая эффективность – это главная проверка. Если решения очень дорого создавать, использовать и обслуживать из-за базы данных, значит, система управления базой данных неадекватна. Экономическая эффективность означает способность системы баз данных эффективно использовать имеющиеся ресурсы, включая трудовые и технологические. Эффективное использование ресурсов – это перспектива автономной компьютеризации (Autonomic Computing), появившейся технологии, которая относится к научному направлению самонастраиваемых систем. Автономные системы – это самоконфигурирование, самоизвлечение, самозащита и самооптимизация.
В действительности автономные функциональные возможности использовались в самых первых коммерческих выпусках реляционной технологии. Наиболее очевидный пример – это оптимизатор запроса, который находится в ядре реляционной технологии баз данных и является «автономным» по своей природе. В контексте формирования и выполнения запроса оптимизатор выполняет много сложных функций, усиленных эвристикой оптимизации и движущими механизмами алгоритмических правил (algorithm-rules engines). Это динамически настраиваемая конфигурация, делающая реляционную систему баз данных, такую, как DB2, коммерчески жизнеспособной. Ныне существующие технологии позволяют привносить автономные возможности в другие, более заметные области технологии реляционных баз данных.
Системам баз данных требуется иногда динамическая настройка. Необходимо много трудовых затрат на конфигурацию. Все это – начальная задача для автономной технологии. Программа самоуправления и настройки ресурсов (Self-Managing and Resource Tuning – SMART) – это инициатива IBM по автономии, предназначенная для уменьшения стоимости настройки и управления в системах DB2 UBD. Первый продукт такого рода появился в DB2 версии 8.1 для платформ Linux, Windows, Advanced Interactive Executive (AIX). Он включает в себя монитор исправности (Health Monitor) и консультант по конфигурации (Configuration Advisor).
DB2 Health Monitor характеризуется новым поколением автономных функций, которые контролируют потребление памяти для кеширования и сортировки. Он также следит за продолжительностью работы приложений, непрерывно отслеживает и оценивает состояние системы баз данных, посылая сигналы тревоги по электронной почте или записывая предупреждения в системный журнал. Инфраструктура вспомогательного инструментария позволяет иметь доступ к данным в режиме реального времени, а также к хронологической информации.
DB2 Configuration Advisor даст мудрый «совет» по конфигурации, позволяющий даже пользователю-новичку грамотно сконфигурировать системы DB2.
Первоначальная стоимость внедрения любого решения для бизнеса всегда принимается во внимание, но стоимость долгосрочной работы и поддержки обычно составляет почти полную стоимость приобретения. Полагаем, что будущее индустриальной мощи – экономичные системы баз данных – будет найдено в автономной компьютеризации. Прилагаемые в настоящее время усилия в области автономной компьютеризации превышают масштаб прежних усилий во много раз. Уровень усовершенствований переопределит в нашем сознании понятие «индустриальная' мощность» технологии баз данных и интегрированных бизнес-решений.
Интеграция с WebSphere MQ
Надежный обмен сообщениями – важное свойство, имеющееся во многих интегрированных бизнес-решениях. В четвертой главе приводится подробное обсуждение обмена сообщениями и типы обмена сообщениями WebSphere MQ, включая датаграммы, публикация/подписка и запрос/ответ. Мы также исследуем структуру сообщения и имеющиеся интерфейсы прикладных программ.
Включение MQ-очередей в DB2 SQL-обращения – это важная ступень интеграции в DB2. Несколько UDF и хранимых процедур добавлены для поддержки различных типов обмена сообщениями MQ, включая функции запрос/ответ и публикация/подписка. Это позволяет DB2 устанавливать такую связь с MQ, будто списки очередности находятся в реляционных таблицах. Следовательно, можно использовать SQL для манипуляции списками очередности MQ на отправление и получение.
На рис. 1.2 функции MQSend и MQReceive доступны через SQL из прикладных программ. Обмен данными происходит между таблицами DB2 и списками очередности MQ. Также имеется приложение MQ Assistant для облегчения пре
Функциональные возможности MQ включаются в DB2 посредством команды enable_MQFunctions. Эти функции MQ базируются на приложении MQ Application Message Interface. С этим широко распространенным стандартом, для взаимодействия DB2-MQ, используются концепции обмена сообщениями: сервисные точки (servicepoints) и стратегия обслуживания (servicepolicies). Сервисная точка – это логическая конечная точка, место, где принимаются и посылаются сообщения. Качество обслуживания (Quality of Service – QoS) определяется стратегией обслуживания. Реализация этих концепций в WebSphere MQ дает дополнительную степень детализации в проектировании и развертывании решений.
Клиентские приложения DB2 могут использовать простой обмен сообщениями для нескольких целей, включая сбор данных, распределение рабочей нагрузки, оповещение приложений и сигнализацию приложениям.
Приложения сбора данных могут вызывать приложения управления цепочками поставок, где данные по управлению запасами, закупкам или данные клиента могут быть извлечены из списков очереди и сохранены в DB2. В девятой главе «Интеллектуальные ресурсы предприятия» мы применяем этот метод «упаковки» данных перед их обработкой OEM-продуктом. Используя распределение рабочей нагрузки, можно распределить заявки на проведение работ из одного списка очередности по многим копиям приложения. Сигнализация приложению – это еще одна полезная штука, важная для совместной обработки данных в приложениях В2В. Используемые таким образом, MQ-сообщения могут функционировать как однонаправленные сообщения-заявки на проведение работ. Оповещающие приложения сообщения обычно содержат в себе данные о деловых событиях и также применимы в совместных бизнес-процессах В2В. Иногда сигнализация приложению осуществляется методом обмена сообщениями баз данных, называемым автоматической публикацией (Automated Publication). По одному сценарию совместные события вставляются в соответствующие таблицы DB2, находящиеся на сетевых серверах. Триггеры, ассоциированные с содержимым таблицы, запускают создание MQ-сообщения. Эти MQ-сообщения становятся связками между внутренними совместными процессами.
WebSphere MQ также поддерживает использование XML в связке с DB2 XML Extender (См. в главе 7 дополнительные сведения по DB2 XML Extenders. – Примеч. авт.). XML Extender имеет функции и сохраняемые процедуры, которые позволяют доступ к функциям DB2 MQ напрямую из приложений DB2 XML. Создание XML-сообщений из таблиц DB2 и разбиение MQ-сообщений в XML-таблицы поддерживаются использованием сохраняемых процедур.
Обычное использование очередей сообщений WebSphere MQ – это поддержка в координации сложных взаимодействий В2В. Поддержка DB2 пересылки и извлечения XML-сообщений через MQ – это один из способов соединения XML Internet-конфигурации со средой обмена сообщениями предприятия путем поддержки обмена информацией, сервиса запросов и уведомлений о событиях.
JЕ-сервисы
2.2.2.1. Java Database Connectivity
Java Database Connectivity (JDBC) – это независимый от платформы и поставщика интерфейс API для реляционных баз данных (см. рис. 2.4).
JavaMail – это интерфейс программы для разработки приложений, основанных на электронной почте и интеграции прикладных программ для деловой сферы с системами электронной почты Internet/ISP (например, протокол доступа к сообщениям в сети Internet [Internet Message Access Protocol 4 – IMAP4], почтовый протокол Internet [Post Office Protocol Version 3 – РОРЗ], простой протокол электронной почты [Simple Mail Transfer Protocol – SMTP]) или корпоративные системы электронной почты (например, IBM Lotus Notes или Microsoft Exchange). Java-Mail может быть использован для разработки новых, основанных на Java систем электронной почты или приложений, работающих с электронной почтой.
2.2.2.3. Java Activation Framework
Java Activation Framework (JAF) используется как база для других пакетов, таких, как JavaMail. JAF поддерживает [М1МЕ]-типы файлов [мультимедийные расширения электронной почты в сети Internet (Multimedia Internet Message Extension – MIME)] или документы, ассоциированные с конкретными JavaBeans, которые обслуживают эти MIME-типы.
2.2.2.4. Протокол Remote Method Invocation/Internet Inter- ORB Protocol
Протокол Remote Method Invocation/Internet Inter-ORB Protocol (RMI-IIOP) обеспечивает инициирование удаленных объектов в J2EE. RMI-IIOP организует объекты. RMI-IIOP позволяет вызов целевых объектов CORBA из среды J2EE или вызов CORBA-клиентом ресурсов J2EE. CORBA – Common Object Request Broker Architecture, технология построения распределенных объектных приложений
2.2.2.5. Язык описания интерфейсов Java (Java Interface Definition Language)
Язык описания интерфейсов Java (Interface Definition Language – Java IDL) интегрирует CORBA с платформой Java, создавая поддержку согласования набора спецификаций IDL со стандартами CORBA.
2.2.2.6. Java Transaction API
Интерфейс (Java Transaction API – JTA) поддерживает промышленный стандарт протоколов двухфазной фиксации и согласование с ресурсами Х/Open ХА, которые, в свою очередь, поддерживают подготовку, фиксацию и откат протокола двухфазной фиксации. JTA обеспечивает управление приложением и контейнерное управление разграничением транзакции, вызовом и выполнением. JTA обеспечивается поддержкой транзакций контейнером.
JTA поддерживает управляемое контейнером и управляемое Bean-компонентом разграничения транзакций. Управляемое контейнером разграничение транзакции дает контейнеру, как прописано в дескрипторе развертывания, возможность управлять всеми аспектами транзакции. Управляемые Bean-компонентом транзакции используют контейнер как менеджера транзакций, но все управление запуском, остановом, фиксацией и откатом инициируется EJB.
2.2.2.7. Сервис сообщений Java (Java Message Service)
Сервис сообщений Java (Java Message Service – JMS) – это интерфейс API, который обеспечивает коммуникацию через асинхронный обмен сообщениями. Он поддерживает оба протокола: точка-точка и публикация/подписка. JMS обеспечивает взаимодействие между приложениями в среде сервера приложений через ориентированное на работу с сообщениями промежуточное программное обеспечение, такое, как WebSphere MQ. Это асинхронное взаимодействие может быть расширено до удаленных, нe-J2EE, систем (унаследованные системы, пакеты программного обеспечения приложения и т.п.). WebSphere MQ обеспечивает гарантированную доставку сообщений.
2.2.2.8. Интерфейс службы имен и каталогов Java(Java Naming and Directory Interface)
Интерфейс службы имен и каталогов Java (JNDI) обеспечивает удаленный и местный сервис размещения объектов, созданный на основе лучших стандартов технологии каталогов, например облегченного протокола службы каталогов IBM (Lightweight Directory Access Protocol – LDAP), метода удаленного вызова (Java Remote Method Invocation – RMI) Registry, службы каталогов Novell (Novell's NetWare Directory Service – NDS), службы имен доменов (Domain Naming System -DNS) и службы объектов (CORBA Object Services – COS). JNDI позволяет клиентским приложениям обнаруживать объекты через их домашний интерфейс, в домене J2EE, LDAP, DNS или в DCE Cell Directory Service (CDS). JNDI также обеспечивает методы для выполнения стандартных операций с каталогами, таких, как ассоциирование атрибутов с объектами и поиск объектов, используя их атрибуты.
2.2.2.9. Java Connector Architecture
Он позволяет проводить интеграцию с унаследованными системами и пакетами ПО, такими, как планирование ресурсов предприятий (ERP), управление цепочками поставок (SCM) и управление взаимодействием с заказчиками (CRM).
2.2.2.10. Сервисы безопасности (Security Services)
Сервисы безопасности обеспечивают аутентификацию и авторизацию доступа к ресурсам J2EE (например, сервлет, JSP, метод EJB).
Сервис живучести обеспечивает возможность применять управляемые контейнером стабильные Bean-компоненты. Он использует JDBC и JTA, чтобы провести обработку живучести. Стабильные Bean-компоненты считываются из базы данных при помощи вызова. Изменения Bean-компонента отражаются в базе данных, в области действия транзакции, в сервисе живучести. Изменения прозрачны для Bean-компонента и для вызывающего приложения.
Microsoft.NET
Большинство ведущих поставщиков серверов Web-приложений привержены J2EE как платформе распределенных приложений программ для электронного бизнеса следующего поколения. Тем не менее Microsoft имеет другой подход к инфраструктуре электронного бизнеса. Их стратегия построена на.NET (см. рис. 2.5).
Microsoft.NET начинался с браузера Internet Explorer и ASP.NET для поддержки на его Web-сервере. Затем это расширилось до прикладных систем с ADO.NET для доступа к данным плюс Web-сервисы. Microsoft Message Queuing (MSMQ) и Microsoft Component Object Model (COM+) использовались для доступа к существующим СУБД. Все это построено с использованием технологии.NET универсального динамичного языка (Common Language Runtime – CLR), которая обеспечивает способность к взаимодействию между.NET-компонентами, написанными на разных языках программирования.
.NET заключает в себе несколько элементов сервера. Компонент Web-формы (Web Forms) обеспечивает разработку пользователем Web-интерфейса. Он позволяет генерировать HTML для показа пользователю, а также проверять достоверность входных данных формы. Компонент XML Web-сервисы (XML Web services) поддерживает вызов любого Web-сервиса, основанного на протоколе доступа (SOAP). Этот компонент интегрирует Web-формы с вызовом Web-сервисов через сервис-процесс определения адреса, через каталог универсальной системы предметного описания и интеграции (Universal Description, Discovery, and Integration – UDDI). Любые разработанные Web-сервисы доступны через этот интерфейс.
Также имеется компонент сервиса для поддержки ActiveX-подобных компонентов. Компонент сервиса – это модификация интерфейса СОМ+ для Microsoft components. Компоненты могут быть написаны на различных языках и затем скомпонованы в среде.NET как динамически подсоединяемая библиотека (DLL). Компоненты сервиса разрешают доступ к элементам управления окном из Web-форм.
В дополнение к интерфейсам компонентов и интерфейсам Web-сервисов,.NET- структура предлагает доступ к другим ресурсам через набор коннекторов. Реляционная база данных ActiveX Data Object, поддерживающая Active Server Page (ASP), выросла до ADO.NET. Среда промежуточного программного обеспечения, ориентированного на работу с сообщениями, доступна через набор классов, которые взаимодействуют с интерфейсом MSMQ. Серверы каталогов, такие, как Microsoft Active Directory, доступны через набор классов доступа к каталогам.
CLR позволяет взаимодействие между приложениями, написанными на различных языках. Он реализует строгий тип присваивания имен, памяти, обработки и управления процессом, а также обработку межъязыковых исключительных ситуаций и динамическую связь между компонентами. Схожий в концепции с CORBA и его языком описания интерфейсов (Interface Definition Language -IDL), CLR способствует межъязыковой коммуникации в реальном времени.
ASRNET позволяет создавать.aspx-файлы для Web-взаимодействия, которое может быть связано с компонентами, Web-сервисами и другими программами (например, с программой Visual Basic.NET) через инфраструктуру.NET.
Таблица 2.1.
Сравнение структур J2EE и.NET
Платформа Java Enterprise Edition
Java стал широко распространенным не только как модель Web-программирования, но также как стратегическая технология программирования почти да всех предприятий. Основы Java – интерфейсы Web-сервера: серверные страниц» Java и сервлеты. Они имеются почти на каждую платформу: Sun Microsystems, BEA Systems, Oracle, IBM. Они доступны по лицензии с открытым исходным кодом, в соответствии с Джакартским проектом для любого Web-сервера Apache.
Кажется естественным, что следующий шаг по ступеньке – это эволюция от Web-сервера до сервера Web-приложений. Это стало возможным благодаря широкому распространению сотрудничества в Java-программировании. Поддерживаемый Sun Microsystems и внедренный в ведущие серверы приложений, включая IBM WebSphere, BEA Systems WebLogic, Oracle Application Server, этот следующий шаг назван Java 2 Enterprise Edition (J2EE).
Стандарт Java разделен на многоярусную структуру (см. рис. 2.1). Java 2 Standard Edition (J2SE) обеспечивает базовую Java-структуру, на которой построены все Java-программы. Это то, что раньше называлось Java Development Kit или JDK.
J2SE содержит классы Abstract Window Toolkit (AWT) и Swing API для графического интерфейса, классы JDBC для доступа к базам данных, классы для устройств ввода/вывода (I/O), для присваивания имен, безопасности и обслуживающей программы. J2SE – это фундамент J2EE.
Java 2 Micro Edition (J2ME) обеспечивает структуру для создания Java-приложений, которые работают в устройствах всепроникающей компьютеризации, включая сотовые телефоны, «карманные» компьютеры (Personal Digital Assistants – PDA) и другие встраиваемые платформы. Программная модель Java для устройств обеспечивает повторное использование приложения на всех приборах, исключая необходимость программировать собственные интерфейсы для каждого прибора.
J2EE обеспечивает структуру конфигурации для предприятия. Пакет имеет возможности, нужные для создания многоярусных приложений для электронного бизнеса. Структура J2EE распределена по следующим ярусам:
• Client_Tier – платформа взаимодействия с конечным пользователем; сюда входят Internet-браузеры, беспроводные устройства, речевые интерфейсы, Java-приложения и Java-апплеты; основной вызов проходит через HTML, HTTP или HTTP Secure (HTTPS) для тонких клиентских приложений и для Internet Inter-ORB (ORB – Object Request Broker, брокер объектных запросов. – Примеч. пер.) -протокола (IIOP) (IIOP – Internet InterORB Protocol – протокол, определяющий передачу сообщений междусетевыми объектами по TCP/IP. – Примеч. пер.), метода удаленного вызова (Remote Method Invocation – RMI) (RMI – технология построения распределенных приложений в спецификации языка Java. -Примеч. пер.) клиентских приложений Java;
• WebJTier – Web-ярус сервисов запросов клиента; обеспечивает файловый Web-сервер (например, HTML, GIF и т.п.) и интерфейсы машинонезависимого Web-программирования (JSP и сервлеты);
• Business_Logic_Tier – этот ярус характеризует J2EE как вычислительную архитектуру сервера приложений, а не как архитектуру Web-программирования; в среде Enterprise JavaBeans (EJB) могут разрабатываться новые компоненты бизнес-приложения и собираться в приложения Java уровня Enterprise; хотя Web-ярус доступен через RMI-ПОР-интерфейсы, эти EJB недоступны для обработки вне Web; например, они могут быть использованы для взаимодействия типа приложение-приложение (application-to-application – А2А) через сервис обмена сообщениями (Java Message Service) и через WebSphere MQ.
Способность к интеграции
Чтобы быть на самом деле эффективными в интегрированных гетерогенных компоновках и конфигурациях реального времени, системы реляционных баз данных должны обеспечивать больше, чем хранение и поиск данных. Они должны иметь компоненты и свойства, которые поддерживают интегрированные приложения и интегрированный доступ к данным, включая доступ к данным, находящимся в других системах, через ориентированное на работу с сообщениями промежуточное программное обеспечение.
Все системы реляционных баз данных имеют следующие возможности: присоединенные процедуры (запускаемые автоматически при возникновении определенных условий), определяемые пользователем функции (UDF – User-Defined Function), и хранимые процедуры, которые часто эффективны в построении интегрированных решений (В пятой главе мы исследуем использование триггеров и UDFs с дополненным решением по электронной почте. – Примеч. авт.). Другие возможности приложений, такие, как поддержка языка структурированных запросов для Java (SQLJ – Structured Query Language for Java), позволяют встраивать SQL в Java-программы. Имеются дополнительные модули (plug-in) SQLJ для интегрированной среды разработки WebSphere Studio Application Developer (http://www-3.ibm.com/software/awdtools/studioappdev/about/V5.html. – Примеч. авт.).
Дополнительные свойства, такие, как объединенный доступ, предоставляют значительные возможности для интегрированных бизнес-решений. Объединенная система баз данных определяется как набор взаимодействующих систем баз данных, которые функционируют автономно. По определению, «объединенная система DB2» – это экземпляр DB2, который поддерживает запрос и поиск данных в гетерогенных источниках данных. В гетерогенных конфигурациях данные могут существовать в других реляционных системах, таких, как Informix (компания Informix – производитель программного обеспечения, а также принадлежащая ей торговая марка), а также в нереляционных системах. В этих конфигурациях подкачка данных и их объединение не всегда осуществимы или удобны. Объединение – это возможность, которая помогает интеграции и стимулирует ее.
Эти и многие другие возможности, очевидно, полезны для разработки интегрированных бизнес-решений. Но мы думаем, что есть три области, которые на самом деле показывают возможности и перспективы DB2 в обеспечении действенной интеграции для бизнес-решений: (1) добавление к объектно-реляционной (0-R) модификации в виде DB2 Extenders, (2) взаимодействие и обмен с ориентированными на работу с сообщениями промежуточными программными средствами (например, WebSphere MQ) и (3) Web-сервисы. Интеграция Web-сервисов и WebSphere MQ – это элементы не жестко связанных структур, которые расширяют возможности и функциональность системы реляционных баз данных.
в индустрии информационной технологии имеется
В наши дни в индустрии информационной технологии имеется выраженная тенденция – клиенты принимают решения о покупках, основываясь на возможностях этой технологии решать проблемы бизнеса, а не на функциональных возможностях технологии. Представители руководящего административного персонала стали больше влиять на принятие решений по информационной технологии. Информационная технология становится инструментом достижения ценности бизнеса, а не вещью в себе. Без перспективы значительной прибыли на инвестированный капитал информационной технологии трудно добиться финансирования.
Очевидно, что наличие в компании экспертов по информационной технологии не просто важно, но критично применительно к принятию решений. Решения принимаются в контексте потребностей бизнеса. На одном уровне значимости наряду с интеграцией оцениваются быстродействие и отдача технологии. Невероятная эйфория первых дней Internet-революции сменилась жаждой ценностей бизнеса. Эти ценности должны проявить себя в улучшении сервиса, увеличении производительности труда служащих, уменьшении эксплуатационных расходов, оптимизации торговых взаимоотношений с деловыми партнерами.
В книге представлен эффективный подход к прагматичному использованию бизнес-технологии в контексте наиболее часто используемых в бизнесе решений. По существу, эта книга дает технологическому сообществу возможность понять основы решений в следующих областях: интеллектуальные ресурсы предприятия, электронная коммерция, интеграция в сфере бизнес для бизнеса (business-to-business – тип интернет-ресурса, ресурс такого типа ориентирован на осуществление операций и поддержку отношений между компаниями). Книга демонстрирует, что эти решения не под силу монолитным приложениям. Они не успевают за быстрыми переменами в современном мире. Эти решения – продукт интеграции основных и промежуточных компонентов программного обеспечения для создания гибких инфраструктур, на базе которых решения могут быть получены.
Поняв потребности клиентов, члены технологического сообщества смогут более эффективно использовать технологии, а не работать в «технологическом бункере» в стороне от потребностей бизнеса. Для сегодняшних клиентов ценности бизнеса определяются использованием технологий для решения стратегических деловых проблем. Эта книга не дает всеобъемлющих универсальных рецептов, но помогает сделать первый шаг на пути понимания бизнес-решений.
Крис Уичер (Chris Wiener),
вице-президент по интеграции корпорации IBM
Предисловие
Мы думаем обобщениями, но живем в деталях.
Альфред Нос Уайтхед (Alfred North Whitehead)
Эта книга затрагивает вопросы технологических решений для бизнеса и вопросы построения вычислительной архитектуры. Эта архитектура проверена практикой при создании бизнес-решений. Книга освещает только часть из большого числа возможных решений, и эти решения даются с упором на элементы, которые интересны профессионалам баз данных. База данных часто наименьший и последний из рассматриваемых элементов. Эта книга не про продукты и приложения, а про интегрированные решения. В центре внимания объединение несопоставимых систем, приложений и продуктов, в единое целое. Интеграция – это область систем управления базами данных, в частности DB2, которой уделяется повышенное внимание. Недостаточно простого сохранения и извлечения данных. Системам баз данных нужно уделить достаточно внимания, как равноправным и необходимым участникам процесса выработки решений для бизнеса. Системы баз данных необходимо интегрировать в целостные бизнес-решения.
Каждая глава книги начинается с известной цитаты. Наша книга отличается хотя бы тем, что вместе цитируются Альберт Эйнштейн и полковник Сандерс (Colonel Sanders). Мы не добивались этого отличия умышленно. Это порождено точкой зрения, что везде есть мудрость, собранная из опыта, проверенная практикой. В этой книге используется практичный подход к действительности: «А это работает?» В контексте этой книги преобладает опыт, лаконично определенный цитатой Олдоса Хаксли (Aldous Huxley), с которой начинается последняя глава: «Опыт – это не то, что с тобой случается. Это то, что ты делаешь с тем, что с тобой случается».
Справедливо говоря, каждая глава имеет отношение к цитате, которая предваряет ее. Итак, мы начали это предисловие с цитаты Альфреда Нос Уайтхеда. Эта цитата – метафора конфликта между обобщениями, требуемыми теорией, и деталями, требуемыми практикой. В последующих главах мы пойдем по тонкой границе между обобщениями и деталями, между теорией и практикой. В этом узком проходе мы найдем будущее передовых бизнес-решений.
Метод, которого мы придерживались при написании этой книги, – показать богатство имеющихся систем, приложений и программ, как огромную пирамиду. Начав подъем у широкого основания, мы быстро движемся наверх, к вершине решения. Опасность этого метода в том, что если вы не очень внимательны, то потребуется время на то, чтобы понять суть. Чтобы рассказать обо всем, нужно написать объемистую энциклопедию, а размер книги служит ограничителем
открывания двери в эту область знаний. Чтобы быть рациональными, мы сфокусировались на знакомых продуктах, приложениях и системах, которые имеют отношение к соответствующим базам данных, описанным в этой книге. Вероятно, использование других продуктов и структур приложений может привести к другим, равно интересным решениям. К сожалению, у нас нет времени просмотреть все возможности.
Мы решили ограничить обсуждение двумя темами, наиболее близкими к рассматриваемому предмету, – производительность и безопасность. Основательное обсуждение этих тем требует больше усилий по детализации, чем отпущенные нам время и объем книги.
В первых четырех главах мы решили представить базовые технологии, которые являются фундаментом технологических бизнес-решений: базы данных, Web-серверы, разработку решения и обмен сообщениями. Информация, представленная в этих главах, научит читателя основам решений, изложенных позднее. Она также даст основы понимания широты бизнес-решений, заострит внимание на вкладе DB2.
Пять глав о решениях составляют ядро книги. Они имеют отношение к знакомым областям технологии бизнес-решений, включая интеллектуальные ресурсы предприятия, В2В (бизнес для бизнеса), всепроникающую компьютеризацию и электронную коммерцию. Имеются определенные продукты, приложения и даже системы, которые сразу приходят на ум, когда рассматриваешь эти разные области решений.
Наш подход в чем-то эклектический. В пятой главе мы сконцентрировались на программе расширения услуг посредством электронной почты, усиленной базой данных и определяемыми пользователем функциями. Это программно-ориентированная глава с упором на базу данных. В главе о В2В мы снова предпринимаем нетрадиционный подход. В этой главе в основном рассматриваются базы данных и связанные с ними технологии, а также содержится немного рассуждений о вычислительной архитектуре. В главе о всепроникающей компьютеризации мы введем пару технологий баз данных, которые могут служить основой любого решения для бизнеса в этой области. Сетевые структуры и вытекающие из них сетевые технологии, используемые в современных решениях, имеют тенденцию к быстрому изменению. Технологии баз данных, представленные в этой главе, обеспечивают устойчивую платформу для решения основных задач в этой быстро развивающейся области.
В главе об интеллектуальных ресурсах предприятия мы обсудим базу данных в контексте распределенной вычислительной архитектуры, в противоположность предыдущим главам. Здесь нужно было показать глубину и ширину вычислительной архитектуры, чтобы полностью понять мощность интеграции и центральную роль базы данных в решении.
В главе об электронной коммерции мы подробнее, чем в начальных главах о решении, рассмотрим распределенную вычислительную архитектуру. В этом типе решения основные элементы (особенно Web-сервер) из тени базы данных выходят на важнейшее место. Когда вы упоминаете о бизнес-решениях,
то большинству людей сразу приходит на ум концепция покупки через Web. Образ клиента видится через специфические свойства Web-серверов, проявляя поведенческую семантику.
В этой главе мы исследуем роль базы данных и ее взаимосвязь с основной составной частью решения по электронной коммерции.
В конце книги читатель найдет глоссарий терминов, список ресурсов и приложения, дополняющие темы в главах.
В конечном счете мы надеемся, что читатели станут понимать базовые технологии, требуемые для выработки бизнес-решений, и будут разбираться в контексте широты решений. Мы ставили цели – приучить думать и самостоятельно исследовать эффективное использование технологии баз данных в бизнес-решениях. Вооруженные пониманием тенденций интеграции в DB2 читатели будут способны создавать свои собственные решения – решения, которые лежат на границе между теорией и практикой, между идеалом и действительностью.
Благодарности
Мы хотим поблагодарить следующих людей за их поддержку: Chris Wicher, Pain Allen, Mark Palmer, Jonathan Adams, Rene Schwartz, Pat Reynolds, Tisha Casta, Pamela Durham, Jan Jackman, Barry Devlin, Feng-wei Chen, Thomas Pack, Lee Cain, Sam McHan, Bill Reed, Naohiko Uramoto.
Мы бы хотели выразить особую благодарность Дану Вульфсону (Dan Wolfson) за его терпение, руководство и поддержку.
Глава 1 DB2 в интеграционных решениях
Прекрасны плоды краткости.
Е.Б. Уайт (Е.В. White)
Взаимосвязь с OEM и интеграция с приложениями
Насколько хорошо пакеты программного обеспечения OEM и их приложения интегрируются с реляционной системой баз данных – это еще одна важная особенность при выборе. Каждый создающий коммерческую реляционную базу данных, в той или иной форме привязан к стандарту языка структурированных запросов (Structured Query Language – SQL). Однако соответствие стандартам – только первый шаг в создании реляционной системы баз данных мирового уровня. То, что отличает одного поставщика от другого, – это приложения. Это верно в области интегрированных бизнес-решений, как ни в какой другой области, где приложения управляют решениями.
В области интегрированных бизнес-решений много хороших пакетов ПО используют системы реляционных баз данных. Большое количество пакетов программного обеспечения – это коллекция приложений, которые обычно вне сферы решений интеграторов и поставщиков реляционных баз данных. Во всех секторах информационной индустрии есть широко известные поставщики лучшего в отрасли программного обеспечения, использующие управление цепочками поставок (supply chain management – SCM) (В первой главе дано представление о SCM в контексте В2В-систем. – Примеч. авт.), планирование ресурсов предприятий (enterprise resource planning – ERP), управление взаимодействием с заказчиками (customer relationship management – CRM) (В шестой главе говорится о мощной программе электронной почты как части системы CRM. Примеч. авт.), интеллектуальные ресурсы предприятия (business intelligence – BI) (Десятая глава знакомит с темой Business Intelligence (интеллектуальные ресурсы предприятия). Примеч. авт.) и приложения для электронной коммерции (eCommerce) (Девятая глава знакомит с темой системы eCommerce
(электронной коммерции). – Примеч. авт.).
Часто небольшие изменения настройки рабочих характеристик SQL или утилит вызывают скачкообразные изменения в производительности OEM-приложений и в производительности решений. С этой целью поставщики приложений, такие, как SAP и Siebel Systems, вошли в альянс с IBM, получив в результате улучшенную интеграцию их продуктов и приложений с DB2.
Иногда понимание того, как OEM-приложения обычно используются, ведет к осознанию необходимости небольших изменений, которые отзываются большим ростом производительности. Например, много инсталляций SAP работают на многоярусных серверах приложений UNIX с сервером базы данных, хранящейся на системах OS/390. Следовательно, поддержка данных формата ASCII -это критический момент для SAP, чтобы предотвратить образование узкого места, получающегося от перегрузки во время преобразования ASCII в EBCDIC (Extended Binary Coded Decimal Interchange Code [IBM] – расширенный двоично-десятичный код обмена информацией).
Многие из этих поставщиков, исходя из назначения приложений, усиливают их такими возможностями, как динамический SQL. В ответ на это были сделаны улучшения в динамическом кешировании SQL линии продуктов DB2, от которых многие разнообразные приложения могут получить преимущества. Другая новейшая возможность приложений поставщиков – интеграция между UDB (Universal DataBase – универсальная система управления базами данных) IBM DB2 и их пакетами программного обеспечения, что уменьшает стоимость и сложность инсталляции. До сих пор другие поставщики ПО воспринимают многоплатформенность DB2 как стимул для расширения поддержки разных платформ их приложениями и в конечном счете баз данных их клиентов.
Взаимодействие с OEM является основным элементом и ключевой особенностью системы реляционных баз данных. С точки зрения как интеграционных разработчиков, так и конструкторов решений, этот элемент будет совершенствоваться, и совершенствование, определенно, не проблема. С точки зрения конструктора, это даст время сосредоточиться на интеграции более высокого уровня и на методе решения.
Web-сервер как краеугольный камень
Краеугольный камень среды Web – это Web-сервер. На сервере есть демон гипертекстового протокола передачи (Hypertext Transfer Protocol daemon -HTTPD), который управляет HTTP-сессиями с браузером в качестве клиентского приложения. Сервер также имеет возможность обслуживать файлы HTML, файлы формата графического обмена (Graphics Interchange Format -GIF) и формата объединенной группы экспертов в области фотографии (Joint Photographic Experts Group – JPEG). Также сервером делаются серверные вставки в Web-страницы при вызове серверных Web-программ, имеются сервисы поддержки масштабируемости и инфраструктуры безопасности хостинга (Хостинг – главенство, выполнение роли ведущего узла. – Примеч. пер.).
Большинство Web-серверов, работающих сегодня, базируются на программе с открытым кодом Apache как компоненте Web-сервера. Apache работает почти во всех ведущих операционных системах. Модульная структура и большой набор возможных конфигураций делают программу весьма подходящей для многочисленных потребностей хоста. IBM поставляет Apache как IBM HTTP-сервер, который может работать на распространенных операционных системах UNIX и Microsoft, на разновидностях Linux, в системах, применяемых реже, таких, как IBM AS/400 и операционная система мэйнфрейма IBM z/OS.
Apache HTTP-серверы поддерживают интерфейсы CGI, FastCGI, препроцессор гипертекста (PHP – Hypertext Preprocessor) и многое другое, доступное через серверные вставки. Большинство Web-серверов поддерживают более чем один программный язык и многочисленные интерфейсы API для Web-программирования.
Web-сервер, по сути, – файловый HTTP-сервер с протоколом управления передачей/протоколом Internet (Transmission Control Protocol Internet Protocol -TCP/IP), в качестве протокола доступа к файлам передающий файлы HTML, GIF и JPEG. С другой стороны, Web-сервер также обеспечивает многочисленные функции безопасности. Во-первых, он реализует возможность ограничения доступа клиентов к Web-серверу. Во-вторых, обеспечивает поддержку протокола защищенных сокетов (Secure Sockets Layer – SSL), взаимную идентификацию между браузером и сервером, основанную на сертификатах SSL с сопровождающим кодированием данных трафика, проходящего между браузером и сервером. В-третьих, он реализует различные алгоритмы аутентификации на уровне HTTP, выдавая приглашения на вход в систему браузеру при просмотре ресурсов Web-сервера с ограниченным доступом.
Конфигурация сети мало зависит от отдельного Web-сервера. Она состоит из многих серверов – это залог масштабируемости и отказоустойчивости. Это означает, что Web-серверы поддерживают кластерную конфигурацию и гибкую систему развертывания. Web-серверы имеют возможности совмещения имен (алиасинг) (посредством чего физическая структура каталога может быть скрыта от пользователя), переадресации унифицированного указателя информационного ресурса (Uniform Resource Locator – URL) на другие Web-серверы, перезаписи URL (для извлечения связей), виртуального хостинга (для управления многочисленными логическими появлениями Web-сервера в инфраструктуре одного физического сервера).
Давайте рассмотрим некоторые из программных интерфейсов Web-сервера.
2.1.1.1. Препроцессор гипертекста РНР
Препроцессор гипертекста РНР – это встроенный в сервер язык скриптов, который воспроизводит структуру языка С в соответствии со стандартом национального института стандартизации США (American National Standards Institute – ANSI). Он реализует возможность объединения команд HTML и РНР в одном файле РНР, подобно серверным страницам Java (Java Server Pages -JSP), рассмотренным ниже.
2.1.1.2. Язык TCL
Инструментальный командный язык (Tool Command Language – TCL) (TCL – свободно распространяемый язык сценариев, обладающий возможностью интеграции различных приложений, объектов и устройств, разработанный в корпорации Sun. -Примеч. пер.) – это другой интерпретатор интерфейса программирования с открытым исходным кодом. Он был разработан для обеспечения пользователей мощным языком, чтобы выполнять работу в широком диапазоне, включая системное администрирование. TCL – это язык, ориентированный на работу со строками, с большим набором операций: смена регистра, сравнение с шаблоном, автоматическое преобразование из одних форматов в другие (например, цифровых форматов).
2.1.1.3. Общий шлюзовой интерфейс/Perl
Общий шлюзовой интерфейс (CGI) – один из Web-стандартов для сопряжения внешних приложений с другими ресурсами и выполнения Web-программ. Созданные CGI-программы помещаются в директорию /cgi-bin для их активизации как вызываемых объектов CGI. CGI-программы могут быть написаны на любом языке: C/C++, FORTRAN (Formula Translator), Perl, TCL, UNIX shell, Visual Basic, AppleScript. Тем не менее основной инструмент, использованный для многих существующих CGI-программ, – это язык Perl.
CGI, по существу, работает как программа командного языка (shell) UNIX. Входные данные в программе CGI, Perl или на другом языке – это переменные среды и стандартные входные данные (stdin). CGI-программа возвращает результаты через стандартное выходное устройство (stdout). Perl имеет набор библиотек для взаимодействия процедур с другими ресурсами, включая модуль интерфейса базы данных (DataBase Interface – DBI) для системы управления реляционной базой данных (Relational Database Management System -RDBMS). Переменная QUERY_STRING среды CGI содержит входные данные из URL.
FastCGI разрешает постоянное соединение. Стандартные входные данные содержат информацию POST и GETHTTP (например, из Web-форм).
Следующие переменные среды – это конкретный ответ на запрос, выполненный шлюзовой программой:
• SERVERPROTOCOL – уровень протокола этого интерфейса;
• SERVER_PORT – номер порта;
• REQUEST_METHOD – метод запроса HTTP (например, GET или POST);
• PATH INFO – путь вызова CGI как указано в URL;
• PATH_TRANSLATED – абсолютный путь вызова CGI, после удаления спуфинга (Спуфинг – способность маршрутизатора реагировать на некоторые сетевые запросы локально, без установления соединения с удаленным пунктом. – Примеч. пер.)
службы имен доменов (Domain Name System – DNS);
• SCRIPTNAME – виртуальный путь вызова CGI;
• QUERY_STRING – информация, следующая за знаком «?» в URL, на которую ссылается этот скрипт; служит элементом входных данных в программу CGI;
• REMOTEHOST – хост, делающий запрос;
• REMOTEADDR – IP-адрес хоста, делающего запрос;
• AUTHTYPE – тип аутентификации запроса;
• REMOTEUSER – имя пользователя для аутентификации и персонализации в CGI-программе;
• REMOTEIDENT – если HTTP-сервер поддерживает запросы на комментарии (Requests for Comments – RFC), обозначение 931, то эта переменная установится для имени удаленного пользователя, извлеченного с сервера;
• CONTENTTYPE – для запросов, которые содержат прикрепленную информацию, такую, как HTTP POST и PUT, – это тип данных содержания (контента);
• CONTENT_LENGTH – длина контента, как задано клиентом.
2.1.1.4. FastCGI
CGI имеет строгие ограничения, потому что он вызывает новый процесс на уровне операционной системы для каждого Web-запроса. Операционная система или интерпретатор Perl должны загружать программу каждый раз заново, для обслуживания нового Web URL-запроса. FastCGI концептуально очень похож на CGI, но имеет два существенных отличия:
• процессы FastCGI постоянны: после завершения запроса он ожидает новый запрос, вместо выхода;
• вместо использования переменных среды операционной системы и каналов, протокол FastCGI мультиплексирует (уплотняет) и передает информацию о переменных, стандартные входные данные, выходные данные, сведения об ошибках через отдельное дуплексное соединение; это позволяет программам FastCGI работать на удаленных машинах, использующих ТСР-связи между Web-сервером и приложением FastCGI.
Приложения FastCGI могут выполняться в одиночном или многопоточном подпроцессе. Для приложений с одиночными подпроцессами Web-сервер поддерживает накопитель процессов (если приложение работает локально), чтобы обрабатывать запросы клиента. Размер накопителя конфигурируется пользователем. Многопоточные приложения FastCGI могут устанавливать многочисленные связи с Web-серверами и обрабатывать их одновременно в отдельном процессе. (Например, встроенная многопоточность Java, сборка мусора, базисные элементы синхронизации и платформенная независимость делают его естественным языком реализации для многопоточных приложений FastCGI.)
2.1.1.5. Активные страницы сервера Microsoft (Microsoft Active Server Pages)
Активные страницы сервера (Active Server Pages – ASP) Microsoft имеются в информационном сервере Internet (Internet Information Services – IIS) Microsoft на различных операционных системах Microsoft. ASP обеспечивает интерфейс программирования сервера для VBScript (произошедшего от Visual Basic) и JScript (Microsoft-версия JavaScript), чтобы создавать динамическое Web-содержание на Web-сервере. ASP-программы обеспечивают обработку Web-форм и проверку полей входных данных, а также обработку электронной почты, файлов, доступа к реляционной базе данных через объектные интерфейсы ASP. Доступ к СУРБД через драйверы открытого интерфейса соединений с базами данных (Open Data Base Connectivity – ODBC) управляется интерфейсом технологии доступа к данным (ActiveX Data Objects – ADO). ADO обеспечивает соединение, запрос и обработку классов (Класс – частично или полностью реализованный абстрактный тип данных. -Примеч. пер.), подобно интерфейсу (Java DataBase Connectivity – JDBC), рассмотренному ниже.
Все эти версии Web-программирования имели одни и те же проблемы. Во-первых, они не были машинонезависимыми. Например, решение Microsoft ASP, написанное для Web-сервера Microsoft Windows 2000, не переносится на Web-сервер Sun Solaris. Во-вторых, они были главным образом процедурными, а не объектно-ориентированными, что ограничивает повторное использование. В-третьих, они имели ограниченную область действия. Эти интерфейсы содействовали коммуникации программы браузер-сервер, но не обеспечивали структуры для развертывания Web-программ в устойчивые Web-приложения. Повторное использование путем расчленения на модули и компоненты было невозможно.
Недавняя встреча в местном книжном магазине иллюстрирует это. Джентльмен горевал из-за того, что Web-сайт его корпорации разросся до 150000 строк кода Perl CGI. Он покупал каждую книгу по Perl, которую ему удавалось найти, пытаясь выполнить требования своего босса по разработке вычислительной архитектуры и планирующемуся повторному использованию Perl для сопровождения этого монолитного монстра. Можно было видеть по его лицу, что большой надежды на успех у него не было.
Желание создать новую базу для следующего поколения Web-приложений вызвало революцию в программировании введением общего языка, который был машинонезависимым и для любой операционной системы. Он был назван Java.
Web-сервисы
Web-сервисы состоят из набора технологий, которые обеспечивают слабую связь между неравноправными системами в Internet. DB2 использует WORF (Web Services Object Runtime Framework) как базовую поддержку доступа Web-сервиса к DB2 (WORF поставляется независимо с DB2 XML Extender Web site или с WSAD (WebSphere Studio Application Developer). – Примеч. авт.).
WORF поддерживает Web-сервисы, которые используют «сборки» (collections) DB2 XML Extender для запроса и сохранения. Метод XML-«c6opKa» осуществляет разбиение XML-документов, которые можно затем сохранять в реляционных таблицах DB2. Метод также обеспечивает создание XML-документов. В любом случае хранимые процедуры, поставляемые с DB2 XML Extenders, выполняют операции манипулирования данными. В дополнение к XML-методу сборок WORF позволяет использование SQL-операций ОБНОВИТЬ, УДАЛИТЬ, ВСТАВИТЬ (UPDATE, DELETE, INSERT) и вызов хранимых процедур. Базирующиеся на SQL Web-сервисы не требуют использования XML Extenders, потому что здесь нет определяемых пользователем соответствий преобразования данных: элементы XML – данные SQL. Хранимые процедуры позволяют динамически поддерживать входные параметры и извлекать данные. Возвращаемое значение данных имеет простое тегирование, используемое в XML по умолчанию. Подробнее Web-сервисы и DB2 рассматриваются в шестой главе «Решение».
Как показано на рис. 1.3, протокол SOAP служит для обеспечения доступа в режиме реального времени (runtime) к сборке XML DB2, хранимым процедурам или к содержанию базы данных через SQL. Инициаторами запроса сервиса может быть любое количество клиентских приложений SOAP, создающих «soap-конверты» – Hypertext Transfer Protocol (НТТР)-сообщения из Web-браузера, предназначенные для поставщика услуг. Другой базовый элемент – это WebSphere Application Server (WAS) с сервисом в режиме реального времени Apache SOAP. WORF позволяет использовать как SOAP-сервис, так и программную модель DADX (Document Access Definition extension) в режиме реального времени. Файл DADX предписывает, как создать Web-сервис, использующий набор операций, определенный либо операторами SQL, либо файлом DB2 XML Extender (DAD).
В этой главе затрагиваются три ключевых типа возможностей, которые должны обеспечивать все системы реляционных баз данных: (1) высокая производительность и высокая надежность, (2) установленные и интегрированные взаимоотношения с лучшими OEM-приложениями, (З) элементы для легкой интеграции с распределенными и слабосвязанными бизнес-конфигурациями. В будущих версиях DB2 можно ожидать значительных улучшений в уровне и качестве интеграции DB2, особенно в распределенных и слабосвязанных конфигурациях.
В следующей главе мы исследуем другую базовую технологию для разработки и совершенствования бизнес-решений – Web-серверы.
Глава 2 Сервер Web-приложений
Internet подобен гигантской медузе. Ты не можешь пройти по нему. Ты не можешь обойти вокруг него. Ты проходишь через него.
Джон Эванс (John Evans)
Web-сервисы: заполнение пробела между JE и.NET
Платформа Web-сервисов – это отраслевая инициатива, поддерживаемая IBM и Microsoft. Широкое распространение Web-сервисов вызвало разработку интерфейсов Web-сервисов на всех ведущих J2EE-платформах. IBM WebSphere Studio Application Developer обеспечивает поддержку для создания интерфейса Web-сервиса для любого компонента WebSphere Java. To же самое справедливо для всех других ведущих J2EE-платформ. Это позволяет средам.NET-отделов работать со средой предприятия и расширенной средой предприятия J2EE. Общий интерфейс Web-сервисов позволяет проводить интеграцию между двумя средами (см. рис. 2.6).
ADT
Абстрактный тип данных (Abstract Data Type). Структурированные типы данных, которые используются для определения столбцов в таблицах.
Bean-компоненты с живучестью, управляемой Bean-компонентом (Bean-Managed Persistence Entity Beans)
Технология Enterprise JavaBeans, которая реализует свой доступ к данным и их обновление в базе данных.
Bean-компоненты с живучестью, управляемой контейнером (Container-Managed Persistence Beans)
Объект Enterprise JavaBeans, который позволяет базовой программе или контейнеру оперировать доступом к данным и их обновлением в базе данных.
CGI
Общий шлюзовой интерфейс (Common Gateway Interface) – программный интерфейс Web-конфигураций первого поколения, главным образом для языка Perl.
CORBA
Технология построения распределенных объектных приложений (Common Object Request Broker Architecture) – стандарт объединения Object Management Group (www.omg.org).
DB2 Everyplace
Реляционная база данных, состоящая из трех основных компонентов: Программа управления базами данных на переносном или PDA-компьютере, синхронизирующий сервер и пакет Personal Application Builder.
DMZ
Демилитаризованные зоны (Demilitarized Zone) – уровень защиты, используемый компаниями, которые хотят иметь собственные Internet-службы, не допуская несанкционированного доступа в их частную сеть. DMZ располагается между Internet и линией защиты внутренней сети, обычно как некая комбинация брандмауэров и других сетевых элементов.
DNS
Служба имен доменов (Domain Naming System) – система, которая устанавливает соответствие Internet-имен с ассоциированными IP-адресами (Internet Protocol).
DTD
Описание типа документа (Document Type Definition).
ebXML
XML для электронного бизнеса (Electronic Business XML) – открытая спецификация, которая создается на уроках прошлого. Она обещает облегчить взаимодействие между компаниями любого размера, из любой отрасли в мировом масштабе. Она создана для решения многих проблем, включая распространение XML-терминологии, интеграции унаследованных решений и снижения стоимости.
EDI
Электронный обмен данными (Electronic Data Interchange) – одна из первых систем, ориентированных на обмен сообщениями, для сближения предприятий. RosettaNet – это первая реализация XML, нацеленная на управление цепочками поставок, с упором на анализ деловых процессов. Все эти технологии, начиная с EDI, выросли в инициативу ebXML.
Ell
Интеграция информации предприятия (Enterprise Information Integration) – методики и реализация интеграции прикладных данных.
Enterprise JavaBeans
Основанная на использовании компонентных объектов бизнес-логика Java и элементы доступа к данным, определенные спецификацией J2EE.
ERP
Планирование ресурсов предприятий (Enterprise Resource Planning) – пакет программ для управления бизнесом, финансовыми и трудовыми ресурсами любого предприятия.
FTP
Протокол передачи файлов (File Transfer Protocol).
GPS
Глобальная система позиционирования (Global Positioning System) – спутниковая система, использующая триангуляционный метод для определения координат места.
HTTP
Протокол передачи гипертекстовых файлов (Hypertext Transfer Prototcol).
J2EE
Платформа Java 2 Enterprise Edition.
MOF
Средство метаобъекта (Meta-Object Facility) – подмножество UML, строго
определяющее модели метаданных.
ORDB
Объектно-реляционная база данных (Object-Relational Database) – реляционная система баз данных, которая расширена путем включения данных объектного типа.
PKI
Инфраструктура общественно-доступных ключей (Public Key Infrastructure) – система цифровых сертификатов, сертификации полномочий и других регистрационных полномочий, которые проверяют и устанавливают подлинность и достоверность каждой стороны, вовлеченной в Internet-транзакцию.
