Введение в WebOLTP

WebOLTP – имя, которое было предложено компанией Sybase, для описания приложений, выполняющих транзакции в Internet, intranet, extranet или традиционных корпоративных сетях. Отличительные черты WebOLTP при ставнении с OLTP-технологией на мэйнфреймах или в системах клиент/сервер :

“Тонкие клиенты” В традиционных системах клиент/сервер для запуска приложений необходимо, чтобы клинтское ПО было заранее установлено. В архитектуре с “тонким” клиентом специализированное программное обеспечение не обязательно устанавливать на клиенте, поскольку исполняемые компоненты могут загружаться с Web site для последующего взаимодействия с клиентом. Таким образом, “тонкий” клиент или клиент с “нулевой инсталляцией” получает два ключевых преимущества при работе в сети: универсальный доступ и уменьшение затрат на инсталляцию и управление. Однако, из-за наличия броузеров и HTML, тонким клиентам для динамического управления бизнес-приложениями необходимо использование дополнительных средств, таких как Java-апплеты. Большие объемы при большом количестве соединений В отличие от приложений клиент/сервер и их предшественников, пользователи WebOLTP могут существенно расширить границы отдела или компании, используя extranets или Internet. С этими новыми приложениями "самообслуживания", доступ больше не ограничивается небольшим количеством клерков, регистрирующих заказы, но вместо этого становится открытым для тысяч пользователей, одновременно выполняющих транзакции. Это потребует хорошо масштабируемую архитектуру сервера для построения WebOLTP приложений. Непредсказуемые нагрузки Приложения с отчетливо выраженным кругом потребителей работают с достаточно ясно определенными наборами действий и нагрузок. Использование WebOLTP-приложений, благодаря открытому кругу пользователей в них, должно привести к непредсказуемым нагрузкам. По мере того, как любое Web-приложение становится доступно, менеджерами Web-узлов обычно затрудняются предсказать, когда и сколько пользователей пытаются загружаться.
Чтобы справляться с неожиданными скачками загрузки при сохранении приемлемого времени отклика, требуется наличие хорошо регулируемых и адаптирующихся систем. Короткий жизненный цикл приложения Каждая следующая генерация приложений кажется обреченной на более короткий жизненный цикл, чем предшествующая. Хотя жизненные циклы, по-видимому, немного удлинятся по мере развития технологии Internet, современные приложения для Сети требуют всего лишь несколько недель или месяцев на разработку, и разрабатываться только в последние 12-18 месяцев. Web-менеджеры стараются корректировать содержимое узла ежедневно и обновлять их графику по крайней мере каждые 9-12 месяцев. Поскольку текущие ожидания потребителя заставят WebOLTP-приложения последовать этому примеру, технология для построения этих систем должна быть очень легкой для использовать и развертывания. Появление WebOLTP-архитектуры Новая архитектура и модель использования призваны удовлетворить строгие требования к WebOLTP-приложениям. Возникновение 3-уровневой или многоуровеневой архитектуры (см. Рис. 4) отвечает потребностям WebOLTP с точки зрения масштабируемости (scalability) и динамического доступа при сохранении всех преимуществ базовой архитектуры. Инфраструктура Web В этой новой модели, пользователи находят и запускают приложения, использующие традиционные страницы и Web-серверы. Но вместо просто загрузки статической страницы, динамическая "апплета" загружается в индивидуальный броузер. К тому же апплета поддерживает высокоскоростные протоколы, которые позволяют ей соединяться непосредственно с сервлетами ("servlets") - ПО, работающим на промежуточном уровне. Обычно сервлеты обеспечивают доступ к одной или более баз данных, реализуют бизнес-логику и возвращают результаты апплете для отображения на клиенте.

Рисунок 4. Трехуровневая архитектура
Хотя многие представители промышленности и ряд поставщиков усиленно “проталкивают” эту архитектуру, по-прежнему ведутся многочисленные споры о точной роли каждого компонента и о ключевых технических требованиях по обеспечению масштабируемости и простоты использования систем на основе WebOLTP. Апплеты Апплеты являются динамически загружаемыми программами, которые управляют логикой представления данных.

В архитектуре WebOLTP апплеты также содержат часть кода, отвечающего за коммуникации, что позволяет им напрямую соединяться с сервлетами, работающими на промежуточном уровне. Существует два метода для построения апплетов. Первый основан на использовании Java и JavaBeans, второй – на основе технологии ActiveX. Безотносительно того, какая технология используется, апплеты реализуют следующие преимущества:

Небольшой объем, что обеспечивает быструю загрузку
Большую интерактивность и более дружественный интерфейс по сравнению с обычными HTML-страницами
Легкость в разработке и сопровождении

Протоколы, отличные от HTTP На сегодня единственным широко распространенным протоколом в Сети является Hypertext Transfer Protocol – . Являясь частью исходной инфраструктуры WWW, HTTP прекрасно подходит для работы со статическими HTML-страницами. Однако он не совсем удобен для интерактивной обработки бизнес-транзакций, поскольку является странично-ориентированным и не поддерживает информацию о состояниях и соединениях. Все это является существенными недостатками, когда речь заходит о приложениях WebOLTP. Для того, чтобы обойти эти слабые места, фактически все эксперты и поставщики предлагают альтернативные протоколы для связи броузера и ПО промежуточного уровня. Ключевые требования для этих новых протоколов включают способность:

Поддерживать информацию о пользователях и транзакциях
Эффективно формировать результирующую выборку и управлять ею
Поддерживать транзакции
Предоставлять надежные механизмы шифрования данных

Среда промежуточного уровня С появлением многоуровневой архитектуры, на промежуточный уровень (или уровни) была перенесена основная тяжесть прикладной обработки. Этот факт делает промежуточный уровень одним из наиболее критических и проблематичных компонентов WebOLTP архитектуры. СУБД Системы управления базами данных остаются важными компонентами всех OLTP систем, в том числе и WebOLTP. Для оптимизации СУБД в архитектуре WebOLTP необходимо:

Поддержка нестабильных нагрузок с отслеживанием таких свойств, как запрос очередей и приоритетов
Высокая скорость соединения с СУБД из Java-приложений
Очереди приложений и управление ресурсами как средства сокращения общего объема ресурсов в системе и достижения стабильной производительности в рамках Internet-транзакции
Обеспечение безопасности, как например, уполномоченная авторизация, т.е.

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

Варианты ПО промежуточного уровня Возможно наиболее спорной областью WebOLTP-архитектуры является вопрос, какая технология больше всего подходит для выполнения и управления бизнес-логикой на промежуточном уровне. Приведем основные требования к ПО промежуточного уровня:

Масштабируемость и производительность при работе с большим количеством пользователей, сессий, транзакций и соединений с БД
Высокопроизводительное соединение броузера и back-end хранилища данных
Поддержка быстрой разработки и развертывания WebOLTP-приложений на промежуточном уровне
Поддержка как синхронного, так и асинхронного управления транзакциями.

На сегодняшний день существует три наиболее распространенных варианта технологий для построения ПО промежуточного уровня: CORBA на основе брокеров объектных запросов (Object Request Brokers - ORBs); мониторы обработки транзакций (Transaction Processing Monitors - TP-Monitors) и серверы Web-приложений.
Каждая из этих технологий имеет свои сильные стороны, но ни одна из них идеально не подходит для требований WebOLTP на промежуточном уровне.
Объекты CORBA имеют превосходные возможности построения многоуровневой архитектуры с вызовом сильно распределенных объектов и прочисми сервисами. К сожалению, сложность общего решения и недостаток надежных средств поддержки ограничивает их применение только квалифицированными разработчиками, которые не боятся “испачкать руки”. К тому же, большинство ORB сегодня имеют примитивные механизмы исполнения на стороне сервера, что также ограничивает эффективность и масштабируемость.
TP мониторы, с другой стороны, имеют устойчивые и отработанные механизмы выполнения, которые предоставляют превосходную эффективность и масштабируемость. Однако, подобно объектам ORB, их общая сложность и собственный интерфейс API зачастую делает TP мониторы трудными в использовании и дорогими с точки зрения установки, управления и поддержки.

Серверы Web-приложений представляют последние решения в области программного обеспечения промежуточного уровня. Технология сервера Web-приложений появилась в результате попытки трансформировать Netscape и Web-серверы Microsoft в серверы приложений; рычагами к этому послужило последнее поколение соответствующих API -(NSAPI и ISAPI). Серверы Web-приложений вообщем являются специализированными (заказными) разработками на основе одного из инструментальных средств создания Web-узла.
Этот мощный набор инструментальных средств действительно ведет к повышению производительности разработчика. Но с другой стороны, масштабируемость существенно ограничена прямым обращением сервера приложений к Web-серверам и отсутствием поддержки не-HTTP протоколов связи.
Чтобы преодолеть слабые стороны существующих систем и удовлетворить требованиям WebOLTP на промежуточном уровне, обеспечивающим масштабируемость и простоту использования, был предложен новый класс системного ПО: серверы транзакций.
Серверы Транзакций Серверы Транзакции объединяют самые лучшие возможности СФЕР и мониторов TP с компонент-основанной разработкой: это дает возможность быстрому созданию масштабируемых WebOLTP приложений. Первыми доступными серверами транзакций станут Sybase Jaguar CTS (Компонентный сервер транзакций) от Sybase, Inc. и Microsoft Transaction Server (прежде известные как Viper). Поскольку спрос на WebOLTP растет, вскоре, по-видимому, должны появиться другие продукты этого класса.

Рисунок 5. Серверы транзакций объединяет самые лучшие возможности TP мониторов и ORB.
Серверы транзакций характеризуются следующими отличительными свойствами:

Предлагают встроенные возможности управления транзакциями.
Обеспечивают механизм запуска и управления сервлетами (servlets).
Поддерживают вызовы распределенных объектов для обеспечения связи в многоуровневых приложениях.
Поддерживают средства быстрой разработки ПО для промежуточного уровня, включая компонентную разработку.

Содержание раздела