Введение| СТАТЬЯ |
20.08.01
|
Borland Application Server 4.5: основные характеристики и возможности применения
© Сергей Орлик
Сергей Макарьин
Алексей Цимбал
КомпьютерПресс #6 2001
Материал любезно предоставлен редакцией КомпьютерПресс,
ведущего российского компьютерного журнала (www.cpress.ru)
Оглавление
ВведениеСегодня интерес к серверам приложений (application servers) становится сугубо прагматическим. Специалисты в области информационных технологий пытаются не просто понять суть этого нового класса программных продуктов, но и применить серверы приложений для решения реальных прикладных задач. К сожалению, в потоке материалов, посвященных серверам приложений, слишком много информации маркетингового характера (какую роль эти продукты занимают в корпоративной стратегии компании, что говорят на Уолл-Стрит и т.п.) и мало фактических данных о возможностях той или иной реализации рассматриваемого класса программных продуктов, об их характеристиках.
Практически ни в одной публикации о серверах приложений не было ни слова сказано о причинах, которые привели к возникновению и формулированию понятия “application server”. Более того, мы видим, что некоторые из этих публикаций если не противопоставляют, то, как минимум, отделяют распределенные вычисления и от использования серверов приложений — достаточно взглянуть на заголовки статей… На самом деле появление серверов приложений является логическим этапом в развитии концепции распределенных вычислений.
Конечно, эта статья в первую очередь посвящена конкретному программному продукту — Borland Application Server 4.5. Однако чтобы понять, откуда берутся те или иные характеристики продукта, попытаемся окинуть взглядом архитектурные тенденции последних лет в области построения инфраструктуры прикладных систем.
С ростом значения информационных технологий для бизнеса и возникновением проблемы актуального отражения изменений в бизнесе на реальные информационные системы, вопрос Enterprise Application Integration (EAI) стал привлекать особое внимание. Интеграция приложений — это не новый модный термин, а реальная проблема, с которой сталкиваются подразделения информационных технологий. С точки зрения IT-департамента, EAI — постоянно действующий бизнес-процесс, реализация которого жизненно важна для обеспечения работоспособности информационных систем и актуальности предоставляемой ими информации.
Интеграция приложений невозможна без интеграции данных. “Правда бывает только одна” (One version of the truth) — так говорит об этом IDC. Идея интеграции данных через их централизацию на серверах баз данных в архитектуре “клиент-сервер” (рис. 1) позволила разработчикам получить работоспособные системы масштабов под разделения с развитыми клиентскими приложениями, учитывающими специфику работы конкретных пользователей. Архитектура и технологии “клиент-сервер” впервые позволили разработчикам рассматривать автоматизацию бизнес-процессов через призму единого информационного хранилища.
 Рис. 1. Архитектура “клиент-сервер” |
К сожалению, следование лозунгу “Используем “клиент-сервер” для построения единой системы автоматизации предприятия!” для многих крупных организаций обернулось увеличением числа незаконченных или не слишком работоспособных проектов. На практике внедрение клиент-серверного подхода в масштабах всего предприятия оказалось делом куда более сложным, чем это представлялось на первый взгляд. Основная проблема концепции “клиент-сервер” в том, что нет ответа на вопрос о местоположении бизнес-логики, тогда как именно в логике заключена суть автоматизации бизнес-процессов, а следовательно, и всего бизнеса в целом. Таким образом, решая проблему интеграции данных, архитектура “клиент-сервер” оставляет без ответа вопрос интеграции прикладной логики. Кроме того, архитектура “клиент-сервер” не решает вопросов масштабируемости прикладных систем.
Интеграция приложений является естественным ответом на всевозрастающие требования автоматизации бизнес-процессов. Важнейшей задачей служб информационных технологий становится организация обмена информацией между разными структурными подразделениями организации, будь то банк, промышленное предприятие или государственный институт. Пытаясь обеспечить согласованность работы приложений уровня подразделения, отделы информационных технологий тратят большие силы и ресурсы на “наведение мостов” между уже созданными приложениями (рис. 2). Иногда результат оказывается успешным — данные сохраняют непротиворечивость и приложения остаются работоспособными.
 Рис. 2. “Стихийная” интеграция приложений |
К сожалению, большая часть команды разработчиков, ответственной за эту самую автоматизацию бизнес-процессов, занимается построением мостов, написанием адаптеров, конвертацией данных и т.п. Аналитическое агентство Forrester Research отмечает, что разработчики тратят до 35% времени на создание интерфейсов и “точек” интеграции приложений и источников данных. В то же время число приложений и их функциональность растет, и с каждым новым приложением увеличивается число связей, причем далеко не линейным образом…
 Рис. 3. Использование единого прикладного транспорта и унификация интерфейсов |
Проблема интеграции приложений не решается в один прием — это постоянный процесс, требующий внимания на всех этапах развития прикладных систем. Естественным решением проблемы EAI является принятие единых правил игры для всех приложений и элементов системы. Такие правила могут быть легко определены через стандартизацию прикладного транспорта и унификацию интерфейсов приложений (рис. 3).
Как известно, самые сложные для исправления ошибки — архитектурные. Их нельзя допускать при определении единых интеграционных подходов, и не хочется тратить время на “изобретение велосипеда”.
Существующие стандарты и реализации связующего программного обеспечения (middleware) позволяют большую часть времени уделять функциональности приложений как таковой, что и требуется от подразделений информационных технологий.
Вновь создаваемые приложения и блоки функциональности естественным образом должны подключаться к универсальной прикладной “шине”. Единожды выполненная адаптация существующего ПО для работы с middleware автоматически приводит к возможности развития прикладной инфраструктуры предприятия без ущерба для работоспособности эксплуатируемых приложений и систем.
Эволюция приложений привела к унификации интерфейсов и прикладного транспорта. Следующим логичным этапом в развитии идеи интеграции приложений является консолидация критичной для бизнеса прикладной логики и повышение управляемости сложных систем (рис. 4).
 Рис. 4. Консолидация критичной для бизнеса прикладной логики |
Серверы приложений (рис. 5) — Application Servers — позволяют разработчикам получить необходимую масштабируемость приложений через концентрацию важнейшей и часто используемой функциональности в отдельных узлах прикладной инфраструктуры предприятия. Таким образом облегчается обновление логики, обеспечивается ее непротиворечивость и актуальность по отношению ко всем элементам инфраструктуры и к самому бизнесу. Качественно возрастает управляемость системы, становится намного проще обеспечить необходимый уровень защиты информации.
 Рис. 5. Архитектура серверов приложений |
Разобравшись с архитектурными проблемами и их возможными решениями, давайте вернемся к основному — Enterprise Middleware-продуктам компании Borland вообще и к Borland AppServer в частности.
Borland на протяжении многих лет развивает линию продуктов VisiBroker (для Java, для C++, для Delphi). VisiBroker является одной из ведущих реализаций CORBA, доступной на широком спектре платформ — Windows, Linux, Solaris, HPUX, AIX, OS/390, VxWorks и др. VisiBroker не просто поддерживает новейшие стандарты (CORBA 2.3), но является “законодателем моды”, впервые предложив разработчикам такие средства, как RMI-over-IIOP (RMI – Remote Method Invocation), Java2IIOP, IIOP-over-HTTP и т.п. На сегодняшний день VisiBroker встроен в продукты таких компаний, как Oracle, Sun Microsystems, Cisco Systems, HewlettPackard, Telcordia Technologies, Hitachi.
Этот список можно продолжать еще очень долго. На VisiBroker и AppServer строят системы управления сетью (от тиражируемой CiscoWork 2000 до частной системы управления сетью UUNET), биллинговые системы (как зарубежных, так и российских производителей), АСУП и АСУТП, работающие и на крупнейших металлургических предприятиях, и в сетях супермаркетов.
В то же время архитекторы и разработчики Borland обладают уникальным опытом создания одного из самых популярных средств разработки Java-приложений — JBuilder (кстати, являющегося одним из крупнейших проектов, полностью написанных на Java).
В качестве лицензиата J2EE, участника Java Community Process (JCP) Board и ключевого члена Object Management Group (OMG), Borland является одной из компаний, формирующих новейшие стандарты индустрии программного обеспечения. Сегодня тысячи распределенных систем работают на основе инфраструктурных middleware-продуктов Borland, обеспечивая поддержку критически важных задач современного бизнеса, промышленности и государственных структур (если вам интересны конкретные примеры и архитектурные решения, пишите по адресу services@borland.ru).
AppServer позволяет разработчикам сконцентрировать свои усилия на создании прикладной логики в виде компонентов EJB (Enterprise JavaBeans). Лежащее в основе AppServer инфраструктурное ядро VisiBroker добавляет к богатству функциональности J2EE мощь коммуникативных средств CORBA IIOP, удовлетворяющих требованиям таких новых и актуальных стандартов, как CORBA Portable Object Adapter (POA), Object-by-value (OBV — передача объектов по значению) и RMI-over-IIOP. С момента своего появления Borland AppServer обеспечивает естественную интеграцию CORBA и J2EE, о которой другие поставщики только начинают говорить.
Приложения, построенные на базе Borland AppServer, используют уникальные технологии для обеспечения требований эпохи мобильного бизнеса и Internet. Интеграция Apache Tomcat в Borland AppServer обеспечи вает поддержку новейших стандартов: Servlet 2.2 и JavaServer Pages 1.1. Приложение Apache Tomcat также предоставляет стандартный HTTP-сервер, который может использоваться совместно с другими популярными Web-серверами. Инструмент администрирования Borland AppServer Console поддерживает визуальное развертывание Java Еnterprise-архивов (EAR) и Web-архивов (WAR) в инфраструктуре серверов приложений. Поддержка стандартов и открытость архитектуры Borland AppServer (рис. 6) обеспечивает доступ к прикладной логике, выполняемой на серверах приложений для различных типов клиентских приложений: XML, HTML, Java приложения и аплеты, WAP, WML, C++ и Delphi.
 Рис. 6. Архитектура Borland AppServer |
Borland AppServer включает в себя высокопроизводительную реализацию механизмов Bean- и Container-Managed Persistence (BMP и CMP), поддерживающую параллельный доступ к компонентам EJB с оптимистической блокировкой, предотвращающей блокирование компонентов и контейнера при выполнении запросов пользователей, одновременно обращающихся к одной и той же прикладной логике. Ядро CMP обеспечивает связи компонентов EJB “один к одному”, “один ко многим” и “многие ко многим”.
Borland AppServer 4.5 — первый J2EE-сер вер, который предлагает базирующиеся на архитектуре Java-коннекторов (J2EE Connector Architecture) стандартные средства интеграции с унаследованными приложениями. Тесно взаимодействуя с ведущими поставщиками программного обеспечения, Borland включил в AppServer 4.5 возможности подключения модулей интеграции с различными ERP- и CRM-системами, мониторами транзакций и системными средствами, в числе которых SAP, CICS, IMS, MQSeries, MS MQ и многие другие.
Borland AppServer 4.5 — сервер приложений, полностью прошедший тесты J2EE 1.2 Compatibility Test Suite (CTS) и получивший соответствующий логотип. В принципе, на этом можно было бы и закончить, адресовав читателя к первоисточникам — спецификациям J2EE и CORBA. Ведь подробное описание всех функций стандартов J2EE и CORBA невозможно уместить в формат статьи. Однако Borland AppServer обладает рядом уникальных характеристик и как самостоятельный продукт, и с точки зрения интеграции с инструментальными средствами.
Критичные бизнес-транзакции
По своей природе транзакции J2EE являются распределенными. Транзакционный сервис Borland AppServer, полностью соответствующий спецификации JTS, поддерживает высокую пропускную способность и обеспечивает получение пользователем данных со скоростью работы в диалоговом режиме. Транзакционный сервис базируется на технологии VisiBroker CORBA и полностью реализует спецификацию JTS 1.0, поддерживая двухфазное завершение транзакций (2PC — 2 Phase Commit), JDBC 2.0 и XA. Реализация JTS в AppServer оптимизирует доступ к базам данных и, кроме того, включает расширенную поддержку протоколирования и восстановления для поддержки сложных распределенных систем и множества источников данных.
Классификация технологий middleware
Transaction Processing Monitor (TPM)
Мониторы транзакций являются одним из старейших типов middleware. Первые реализации TPM, такие как IBM CICS, были очень популярны в 70-е годы. Основные проблемы TPM — монолитность и отсутствие поддержки объектно-ориентированного подхода (ООП). Новый класс TPM — объектные мониторы транзакций — уже не является самостоятельным ПО, а относится к службам объектно-ориентированных распределенных сред — CORBA/J2EE и COM.
Message-oriented Middleware (MoM)
MoM, как и TPM, относится к первой волне middleware. По своей сути системы MoM весьма просты. Они включают только четыре основные функции: отправить, получить, сохранить в файле и удалить. Главное преимущество использования MоM в распределенной среде — гарантия доставки сообщений, основанная на асинхронной работе с очередями сообщений. Однако API низкого уровня, отсутствие поддержки ООП и стандартов, обеспечивающих интеграцию MoM от разных поставщиков, привели к развитию нового поколения MoM в качестве сервисов платформ CORBA/J2EE и COM.
Несмотря на развитость сервисов платформы COM+ и, даже в большей степени, разрабатываемого преемника — .NET, это семейство платформ Microsoft для создания распределенных объектных приложений доступно только на платформе Windows. Отсутствие процесса стандартизации как такового, тесная интеграция с операционной системой и, как следствие, закрытость этой платформы и отсутствие альтернативных реализаций ограничивают применимость семейства платформ COM+ /.NET для создания прикладной инфраструктуры предприятия.
Разрабатываемая с 1989 года консорциумом OMG (Object Management Group) архитектура CORBA (Common Object Request Broker Architecture) — результат работы ведущих специалистов из более чем 800 компаний и организаций. Четкий процесс стандартизации, который включает в себя и аспекты взаимодействия реализаций CORBA от разных поставщиков (интероперабельность), независимость от языков программирования и операционных сред, фундаментальная поддержка ООП и многие другие уникальные характеристики сделали CORBA ведущим стандартом в области инфраструктурного middleware.
Java 2 Enterprise Edition (J2EE)
Платформа J2EE, развиваемая в рамках открытого процесса стандартизации JCP (Java Community Process), впервые предложила цельную компонентную модель — EJB (Enterprise JavaBeans), ориентированную на создание серверной бизнес-логики. Использование архитектурных достижений CORBA в важнейших службах J2EE, вплоть до уровня распределенного взаимодействия, в основе которого лежит протокол CORBA IIOP (Internet Inter-ORB Protocol), обеспечило отличную масштабируемость систем, построенных на платформе J2EE.
Сервер приложений — новая промышленная парадигма, доступная в виде программных продуктов от целого ряда поставщиков ПО, включая IBM, Borland, BEA Systems и Sun. Он эффективно объединяет различные связующие средства и технологии, позволяющие получить готовую платформу для развертывания распределенных приложений масштаба предприятия.
Концепция сервера приложений в настоящее время признана критически важной для развертывания компонентов бизнес-логики в распределенной среде. В этом контексте Enterprise JavaBeans стал стандартом de facto для создания масштабируемых прикладных систем.
Реализация серверов приложений на основе CORBA позволяет обеспечить прозрачную интеграцию и доступность прикладных систем в режиме 24x7. Это позволяет рассматривать такие серверы приложений в качестве критически важного элемента прикладной инфраструктуры предприятия.
Дополнительную информацию Вы можете получить в компании Interface Ltd.
Отправить
ссылку на страницу по e-mail
Обсудить на форуме Inprise/Borland
| Interface Ltd. Отправить E-Mail http://www.interface.ru |
|
| Ваши замечания и предложения
отправляйте автору По техническим вопросам обращайтесь к вебмастеру Документ опубликован: 20.08.01 |