Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Когда применение SOAP становится неэффективным

Фрэнк Тети

Спецификация SOAP (Simple Object Access Protocol) не всегда является самой “чистой” моделью интеграции корпоративных приложений. Конечно, архитектура Web-сервисов консорциума W3C стала стандартным подходом де-факто, обеспечивающим совместную работу приложений, основанных на Microsoft Windows и J2EE. Что же касается интеграции приложений в вашей интрасети, то вы можете обратиться к серверу IBM zSeries класса мэйнфрейм или к другой аналогичной платформе с Web-сервисами, использующими язык XML и спецификацию SOAP.

Однако не исключено, что при переходе с устаревших, основанных на языке COBOL OLTP-приложений на Java-приложения время отклика в вашей сети и нагрузка на центральный процессор сервера приложений скачкообразно возрастут. Если вы, например, переделываете свое унаследованное приложение учета поступлений заказов в сервис SOAP, это может вылиться практически в двукратное увеличение загрузки процессора и привести к заметному увеличению времени отклика вашего приложения. К тому же использование архитектуры Web-сервисов SOAP менее эффективно, чем применение Java-приложений.

Это как раз тот самый случай, когда для создания Web-сервисов лучше использовать не спецификацию SOAP, а иной, альтернативный подход. Один из таких альтернативных подходов базируется на приложении J2EE Blueprints компании Sun, однако в этой модели проектирования слишком широко используются объекты, что может привести к чрезмерному снижению скорости обработки транзакций. В нашей компании QVC, специализирующейся на розничной торговле, мы развертываем более простую, кроссплатформенную прикладную архитектуру XML, не использующую спецификацию SOAP. Эта XML-архитектура, которой требуется всего несколько объектов, легко реализуется в рамках Java-приложения или Java-сервлета.

Клиентская сторона против серверной стороны

Язык XML действительно становится для больших разношерстных распределенных компьютерных сред языком “лингва франка”, т. е. понятным для любой из них. Приложения получают и генерируют данные в формате XML. Модель интеграции, которую мы внедрили в своей компании, становится уже не трехуровневой, а двухуровневой клиент-серверной моделью. Как и в случае с моделью RPC SOAP, данные XML пересылаются через сеть. Однако в отличие от архитектуры SOAP наша модель не содержит конверта, в который упаковывается зашифрованная информация для сообщения и его заголовка. Существенная вычислительная нагрузка, вызываемая обработкой XML-надстройки сообщения SOAP, является главным уязвимым местом архитектуры W3C. Приложениям обработки транзакций, столь чувствительным к задержкам трафика, совершенно ни к чему этот лишний “воз”.

Вы можете сконфигурировать XML-интрасеть просто для того, чтобы отправлять и получать по сети сообщения XML. Поскольку при этом используются кроссплатформенные компоненты, такие, как модуль трансформации XSLT (Extensible Stylesheet Language Transformation), применяемый при создании HTML-страниц и серверов приложений J2EE, то эта архитектура практически не ограничивает вас в выборе способов конфигурирования своих процессоров, что является ценным ее преимуществом. Для многих организаций движущим фактором, определяющим потребность в хостировании приложений, можно назвать снижение совокупной стоимости владения, которая включает в себя затраты на разработку и внедрение, хостирование и техническую поддержку приложений.

Основная цель использования этой упрощенной XML-архитектуры — снижение накладных расходов на синтаксический анализ сообщений XML и, как следствие, повышение производительности приложений. Эта архитектура является гибкой и с точки зрения XSLT-обработки. Новая XML-модель позволит вам реализовать более дешевый способ повышения производительности XSLT-обработки (т. е. процесса преобразования файлов XML в документы HTML) — не за счет покупки нового оборудования и использования Java-ресурсов, а путем переноса этой обработки на ваш сервер HTTP или клиентский браузер. Если вы собираетесь выполнять массовую рассылку документов XML, наиболее предпочтительным вариантом будет перенос процесса XSLT-трансформации на сервер HTTP. Подход, основанный на выполнении XSLT-трансформации на клиентской стороне, чуть более сложен. Если вы предпочитаете выполнять XSLT-обработку на клиентской стороне, то ваш браузер должен поддерживать XSLT 1.0 или XSL-WD, как это делают браузеры Microsoft Internet Explorer 5+, Netscape 6+ и Mozilla. Кроме того, требуется, чтобы объем оперативной памяти ваших настольных компьютеров составлял не менее одного гигабайта.

Между тем сервер zSeries компании IBM оптимизирован для приложений, интенсивно работающих с устройствами ввода-вывода, систем управления базами данных и приложений с параллельной обработкой очередей, так что было бы слишком расточительно использовать этот суперсовременный сервер для обработки HTTP-запросов с выдачей статического контента и файлов в форматах GIF и XSL. Позвольте этому мощному универсальному серверу обрабатывать вызовы базы данных, а XSLT-обработку доверьте своему серверу и клиенту HTTP.

Однако сердцем этой архитектуры интеграции приложений, основанной на XML, является сервер приложений J2EE, который обрабатывает все входящие запросы XML и интегрируется с базами данных. Он поддерживает язык программирования Java Server Pages (JSP), приложения Enterprise JavaBeans (EJB) и технологию Java Servlets.

Интерактивная среда разработки WSAD

Итак, каким образом следует проектировать и внедрять данную эталонную архитектуру? Для этой цели мы используем WebSphere Studio Application Developer (WSAD) 5.0.1 компании IBM. WSAD — интерактивная среда разработки базовых приложений J2EE компании IBM. Хотя WSAD основана на ПО с открытым исходным кодом Eclipse 2.1 (которое является базовой связующей средой для XML-интрасети), она ориентирована на разработку приложений J2EE с применением сервера WebSphere Application Server компании IBM. Платформа Eclipse, ориентированная на независимых производителей ПО, включает в себя исполняемые модули, позволяющие загружать подключаемые модули (plug-in) и выполнять их. Эти подключаемые модули выполняют синтаксический анализ сообщений XML и другие аналогичные задачи. (Однажды в ходе выполнения одного проекта разработки с применением продукта BEA WebLogic мне довелось использовать Eclips, который поддерживает не только платформу IBM.)

Вообще говоря, эталонная архитектура XML подобна архитектуре JSP Model 2 Architecture. Клиентское приложение делает запрос контроллерному сервлету, обрабатывающему этот запрос, и отправляет ответ клиенту. Но, если JSP Model 2 отправляет ответ только в формате HTML-страницы, то архитектура XML возвращает ответ в виде либо XML-, либо HTML-сообщения. Кроме того, архитектура JSP Model 2 чисто серверная и поэтому не позволяет переносить XSLT-трансформацию на сервер HTTP или клиентский браузер.

Подобно большинству корпоративных прикладных инструментальных средств язык XML предназначен главным образом для ввода данных в СУБД и извлечения их посредством Интернет-технологий. Для определения данных — не только вводимых в базу данных или извлекаемых из нее, но и необходимых для XML-структуры и основной таблицы стилей XSLT (она используется при создании HTML-страниц) — архитектура XML задействует команды SQL. Именно на этом этапе и вступает в игру программа-мастер WSAD (см. “Генерация запросов SQL с помощью небольшой программы-мастера”).

Рассмотрим базовую бизнес-логику обработки данных XML в рамках Web-приложения (рис. 2). Сервлет EmployeeServlet получает запрос с клиентского браузера и передает его объекту SQLToXMLds. Класс SQLToXMLds, интегрированный с WSAD, обеспечивает связь с базой данных и отображение результатов JDBC Resultset в сообщение XML. Если вы хотите ввести, обновить или удалить данные из базы данных с помощью XML, то вам придется использовать класс XMLToSQL.

Класс SQLToXMLds организует для Web-приложения пул соединений с базой данных, что позволяет существенно уменьшить время отклика приложения, поскольку вместо инициации новых соединений с базой данных можно повторно использовать уже имеющиеся. Большинству корпоративных приложений J2EE требуются пулы соединений с базой данных.

Подобно большинству Web-приложений наша модель применения XML позволяет посылать запросы в базу данных и получать результаты. Запрос отсылается сервлету, который запускает объект SQLToXMLds. После этого объект SQLToXMLds соединяется с СУБД и на клиентский браузер возвращаются файлы HTML.

Упрощенная модель XML

Итак, если спецификация SOAP для вашей прикладной среды слишком неэффективна, попробуйте использовать для интеграции своих приложений с приложениями J2EE упрощенную модель XML. Она позволяет снизить интенсивность сетевого трафика за счет передачи через вашу интрасеть лишь сообщений XML по протоколу HTTP. Эта модель переносит синтаксический анализатор XML (главный источник накладных расходов на обработку сообщений XML) на наиболее эффективную платформу, и ваше приложение работает быстрее.

Недостатком этой архитектуры является то, что, если вам необходимо выполнять свою XSLT-обработку не на сервере, а на клиентской системе, вам потребуются не только серверы приложений J2EE, но и более современные версии браузеров. Однако ведь вы хотите, чтобы ваши переделанные приложения работали эффективно, поэтому игра стоит свеч..





  
2 '2004
СОДЕРЖАНИЕ

бизнес

• "Коммунальные вычисления". Вы верите в их возможность?

• Доктрины производителей

• На пути к электронному голосованию

инфраструктура

• Телефоны VoWLAN: готовность номер один

• Инженерная инфраструктура центра данных, или Решения NCPI

• Пора обзаводиться тестовым инструментарием

• iSCSI-сети хранения данных

информационные системы

• Когда применение SOAP становится неэффективным

• Программные средства технической поддержки клиентов

сети связи

• Новые IP-телефоны

• УАТС как услуга

кабельные системы

• Медиаконвертеры позволяют модернизировать сеть, не обременяя бюджет

• Соблюдайте правила установки огнезадерживающих средств

защита данных

• Вооружитесь камерами и замками

• Говоря на языке SAML


• Калейдоскоп



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх