Borland Application Server 4.5: основные характеристики и возможности применения
Сергей Орлик, Сергей Макарьин, Александр Цимбал 
Безопасность распределенных вычислений
Borland JBuilder: быстрая разработка и развертывание компонентных систем
Взаимодействие приложений Delphi и C++ с компонентами EJB в Borland AppServer
Защита от сбоев и кластеризация
AppSerever Console и Borland AppCenter
Классификация технологий middleware
Соответствие принятым (1.2) и разрабатываемым (1.3) стандартам J2EE
Платформы, поддерживаемые Borland Application Server 4.5.x
Сегодня интерес к серверам приложений (application servers) становится сугубо прагматическим. Специалисты в области информационных технологий пытаются не просто понять суть этого нового класса программных продуктов, но и применить серверы приложений для решения реальных прикладных задач. К сожалению, в потоке материалов, посвященных серверам приложений, слишком много информации маркетингового характера (какую роль эти продукты занимают в корпоративной стратегии компании, что говорят на Уолл-Стрит и т.п.) и мало фактических данных о возможностях той или иной реализации рассматриваемого класса программных продуктов, об их характеристиках.
Практически ни в одной публикации о серверах приложений не было ни слова сказано о причинах, которые привели к возникновению и формулированию понятия «application server». Более того, мы видим, что некоторые из этих публикаций если не противопоставляют, то, как минимум, отделяют распределенные вычисления и от использования серверов приложений — достаточно взглянуть на заголовки статей... На самом деле появление серверов приложений является логическим этапом в развитии концепции распределенных вычислений.
Конечно, эта статья в первую очередь посвящена конкретному программному продукту — Borland Application Server 4.5. Однако чтобы понять, откуда берутся те или иные характеристики продукта, попытаемся окинуть взглядом архитектурные тенденции последних лет в области построения инфраструктуры прикладных систем.
Интеграционная инфраструктура
С ростом значения информационных технологий для бизнеса и возникновением проблемы актуального отражения изменений в бизнесе на реальные информационные системы, вопрос Enterprise Application Integration (EAI) стал привлекать особое внимание. Интеграция приложений — это не новый модный термин, а реальная проблема, с которой сталкиваются подразделения информационных технологий. С точки зрения IT-департамента, EAI — постоянно действующий бизнес-процесс, реализация которого жизненно важна для обеспечения работоспособности информационных систем и актуальности предоставляемой ими информации.
Интеграция приложений невозможна без интеграции данных. «Правда бывает только одна» (One version of the truth) — так говорит об этом IDC. Идея интеграции данных через их централизацию на серверах баз данных в архитектуре «клиент-сервер» (рис. 1) позволила разработчикам получить работоспособные системы масштабов подразделения с развитыми клиентскими приложениями, учитывающими специфику работы конкретных пользователей. Архитектура и технологии «клиент-сервер» впервые позволили разработчикам рассматривать автоматизацию бизнес-процессов через призму единого информационного хранилища.
К сожалению, следование лозунгу «Используем «клиент-сервер» для построения единой системы автоматизации предприятия!» для многих крупных организаций обернулось увеличением числа незаконченных или не слишком работоспособных проектов. На практике внедрение клиент-серверного подхода в масштабах всего предприятия оказалось делом куда более сложным, чем это представлялось на первый взгляд. Основная проблема концепции «клиент-сервер» в том, что нет ответа на вопрос о местоположении бизнес-логики, тогда как именно в логике заключена суть автоматизации бизнес-процессов, а следовательно, и всего бизнеса в целом. Таким образом, решая проблему интеграции данных, архитектура «клиент-сервер» оставляет без ответа вопрос интеграции прикладной логики. Кроме того, архитектура «клиент-сервер» не решает вопросов масштабируемости прикладных систем.
Интеграция приложений является естественным ответом на всевозрастающие требования автоматизации бизнес-процессов. Важнейшей задачей служб информационных технологий становится организация обмена информацией между разными структурными подразделениями организации, будь то банк, промышленное предприятие или государственный институт. Пытаясь обеспечить согласованность работы приложений уровня подразделения, отделы информационных технологий тратят большие силы и ресурсы на «наведение мостов» между уже созданными приложениями (рис. 2). Иногда результат оказывается успешным — данные сохраняют непротиворечивость и приложения остаются работоспособными.
К сожалению, большая часть команды разработчиков, ответственной за эту самую автоматизацию бизнес-процессов, занимается построением мостов, написанием адаптеров, конвертацией данных и т.п. Аналитическое агентство Forrester Research отмечает, что разработчики тратят до 35% времени на создание интерфейсов и «точек» интеграции приложений и источников данных. В то же время число приложений и их функциональность растет, и с каждым новым приложением увеличивается число связей, причем далеко не линейным образом...
Проблема интеграции приложений не решается в один прием — это постоянный процесс, требующий внимания на всех этапах развития прикладных систем. Естественным решением проблемы EAI является принятие единых правил игры для всех приложений и элементов системы. Такие правила могут быть легко определены через стандартизацию прикладного транспорта и унификацию интерфейсов приложений (рис. 3).
Как известно, самые сложные для исправления ошибки — архитектурные. Их нельзя допускать при определении единых интеграционных подходов, и не хочется тратить время на «изобретение велосипеда».
Существующие стандарты и реализации связующего программного обеспечения (middleware) позволяют большую часть времени уделять функциональности приложений как таковой, что и требуется от подразделений информационных технологий.
Вновь создаваемые приложения и блоки функциональности естественным образом должны подключаться к универсальной прикладной «шине». Единожды выполненная адаптация существующего ПО для работы с middleware автоматически приводит к возможности развития прикладной инфраструктуры предприятия без ущерба для работоспособности эксплуатируемых приложений и систем.
Эволюция приложений привела к унификации интерфейсов и прикладного транспорта. Следующим логичным этапом в развитии идеи интеграции приложений является консолидация критичной для бизнеса прикладной логики и повышение управляемости сложных систем (рис. 4).
Серверы приложений (рис. 5) — Application Servers — позволяют разработчикам получить необходимую масштабируемость приложений через концентрацию важнейшей и часто используемой функциональности в отдельных узлах прикладной инфраструктуры предприятия. Таким образом облегчается обновление логики, обеспечивается ее непротиворечивость и актуальность по отношению ко всем элементам инфраструктуры и к самому бизнесу. Качественно возрастает управляемость системы, становится намного проще обеспечить необходимый уровень защиты информации.
 |
|
Borland AppServer 4.5
Разобравшись с архитектурными проблемами и их возможными решениями, давайте вернемся к основному — Enterprise Middleware-продуктам компании Borland вообще и к Borland AppServer в частности.
Borland на протяжении многих лет развивает линию продуктов VisiBroker (для Java, для C++, для Delphi). VisiBroker является одной из ведущих реализаций CORBA, доступной на широком спектре платформ — Windows, Linux, Solaris, HP-UX, AIX, OS/390, VxWorks и др. VisiBroker не просто поддерживает новейшие стандарты (CORBA 2.3), но является «законодателем моды», впервые предложив разработчикам такие средства, как RMI1 -over-IIOP, Java2IIOP, IIOP-over-HTTP и т.п. На сегодняшний день VisiBroker встроен в продукты таких компаний, как Oracle, Sun Microsystems, Cisco Systems, Hewlett-Packard, 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.
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 оптимизирует доступ к базам данных и, кроме того, включает расширенную поддержку протоколирования и восстановления для поддержки сложных распределенных систем и множества источников данных.
|
|
Безопасность распределенных вычислений
Обеспечение защиты информации является ключевым требованием для всех современных информационных систем. Borland AppServer предлагает средства обеспечения безопасности, включающие всестороннюю поддержку SSL2, работу через межсетевой экран и развитые механизмы аутентификации и авторизации.
Например, для аутентификации AppServer и Borland Security Service поддерживают механизмы user/password с хранением учетной информации либо на сервере приложений, либо путем использования существующих методов (Windows NT/SAM, UNIX/NIS). Еще один, весьма удобный и популярный тип аутентификации как клиента, так и сервера в Borland Security Service — применение сертификатов Х.509 с поддержкой инфраструктуры PKI и протокола LDAP3. Для поддержки механизмов авторизации в Borland AppServer реализован стандарт EJBsecurity, позволяющий авторизовать доступ субъектов и их объектов к вызовам отдельных методов любых компонентов. Необходимо отметить, что можно легко сочетать компоненты как с авторизацией и (или) аутентификацией, так и без оных. Полноценная поддержка стандарта де-факто для защиты прикладного уровня — протокола SSL — означает возможность гибкого применения криптографических механизмов (DES, 3DES, RC4, RSA, MD5, SHA) для шифрования данных и проверки целостности при передаче данных по сети.
Borland Gatekeeper, являющийся частью VisiBroker и AppServer, обеспечивает тесную интеграцию с технологиями межсетевых экранов (МЭ, firewall), предоставляя внешним пользователям и клиентам безопасный доступ к системе из общедоступных сетей (например, Internet) через firewall. Gatekeeper соответствует новейшей спецификации OMG Firewall. Он позволяет эффективно и безопасно работать через МЭ, используя такие протоколы, как IIOP, IIOP/SSL, IIOP/HTTP и IIOP/HTTPS.
Кроме того, Gatekeeper поддерживает дополнительную авторизацию на основе IP-адресов, подсетей, портов и т.д. в приходящих запросах, а также авторизацию и шифрование трафика с помощью SSL.
|
|
Borland JBuilder: быстрая разработка и развертывание компонентных систем
Borland AppServer легко интегрируется с любыми средами разработки на базе Java 2, уменьшая цикл разработки и ослабляя нагрузку на отделы информационных служб организаций и предприятий в условиях недостатка квалифицированных разработчиков. Интеграция с Borland JBuilder, безусловным лидером на рынке Java-инструментария (рис. 7), позволяет с легкостью создавать не только клиентские приложения, но и сложную прикладную логику в виде компонентов EJB с помощью интуитивно понятных средств RAD (Rapid Application Development). Как результат такой интеграции, разработчики, использующие JBuilder и AppServer, могут создавать, тестировать, отлаживать и развертывать прикладные компоненты непосредственно из JBuilder IDE (Integrated Development Environment), добиваясь максимальной продуктивности и высокого качества создаваемого программного обеспечения.
Весной 2001 года компания Borland выпустила Borland Enterprise Studio for Java — продукт, включающий Rational Rose, JBuilder Enterprise, JBuilder Rose Link, Macromedia Dreamveawer Ultra Dev и Borland AppServer 4.5. Таким образом, разработчики получили интегрированный комплекс инструментов, полностью охватывающих весь жизненный цикл современных программных систем: анализ, моделирование, проектирование, разработку, Web-дизайн и развертывание компонентов прикладной логики (рис. 8).
|
|
Взаимодействие приложений Delphi и C++ с компонентами EJB в Borland AppServer
Реализация в Borland AppServer интерфейсов EJB и JNDI «поверх» CORBA (VisiBroker for Java 4.5) позволяет естественным образом обеспечить использование EJB-компонентов как в качестве серверов для любого CORBA-клиента, так и в качестве клиента для взаимодействия с любыми CORBA-серверами. Последнее обстоятельство может оказаться очень полезным в ситуации, когда необходимо «включить» в распределенную систему ранее написанный код, например на C++, расширив тем самым функциональность вашего сервера приложений. Таким способом вы можете обойти неприятное ограничение спецификации EJB, запрещающее загрузку native-библиотек в коде компонента EJB.
В Borland AppServer поддерживается взаимодействие с CORBA-клиентами, соответствующими как спецификации 2.3, так и спецификациям более ранних версий. Критичным здесь является поддержка технологии Object-By-Value (OBV). Специально для обеспечения взаимодействия с реализациями CORBA, не поддерживающими OBV, Borland предусмотрел альтернативный путь, основанный на использовании так называемого Simplified IDL (SIDL). Соответствующий SIDL-код может быть получен на основе байт-кода для Home-интерфейса EJB-компонента, после чего клиент создается в классическом стиле CORBA. При этом SIDL.idl определяет упрощенный вариант описания служебных классов Java и компонентов EJB для доступа из CORBA-приложений, созданных в Delphi и на C++ (см. листинг).
|
|
Защита от сбоев и кластеризация
Borland AppServer включает в себя средства автоматической кластеризации EJB-контейнеров и их сервисов. Эта возможность, не требующая работы со сложными файлами настроек и накладных расходов на администрирование, является на сегодня уникальной в индустрии. Даже в маловероятной ситуации сбоя AppServer самостоятельно задействует failover-средства для обеспечения доступа к компонентам EJB, помещенным в другие экземпляры контейнеров или в кластерные контейнеры. Надежность управления распределенными системами и их высокая готовность может быть повышена за счет совместного использования AppServer и Borland AppCenter.
|
|
AppSerever Console и Borland AppCenter
AppServer включает в себя графическую консоль, выполняющую роль главного центра управления. Консоль позволяет управлять серверами, останавливать и запускать те или иные сервисы и т.д. Кроме того, консоль позволяет управлять архивами EJB (.jar, .ear), Web-архивами (.war) и контейнерами, устанавливать характеристики развертывания компонентов, включая детальную работу с EJB deployment descriptor как в XML-представлении, так и на визуальном уровне. Как правило, AppServer запускается на мощных UNIX- или Windows NT-серверах, в то время как консоль может быть размещена на любом компьютере, с которого вам удобно управлять распределенной системой. Имея один экземпляр консоли, вы получаете доступ к любому серверу в сети.
Консоль Borland AppServer (рис. 9) и интегрированный редактор XML-описателей прикладных компонентов (XML DDE — Deployment Descriptor Editor) предоставляет развитой графический интерфейс для управления серверами приложений, их сервисами и компонентами. Borland AppServer поддерживает так называемый HotDeploy — развертывание и обновление компонентов EJB без остановки серверов, контейнеров и сервисов, обеспечивая непрерывную работу в операционном режиме 24×7.
Консоль может использоваться для просмотра не только атрибутов EJB-контейнера, но и параметров его производительности. Параметры производительности могут быть полезны, например, для определения времени, затрачиваемого контейнером для выполнения активации объектов или организации вызова удаленного метода. Эта информация помогает обнаружить проблемы в сети (например, если контейнер тратит большую часть времени на организацию удаленных вызовов, а не на выполнение кода методов компонентов). Пользователь может выбрать различные форматы отображения такой информации — графики, двух- и трехмерные гистограммы, таблицы.
Более функциональный, чем консоль AppServer, Borland AppCenter (рис. 10) является уникальным инструментом менеджмента и мониторинга распределенных решений на основе технологий J2EE и CORBA. Интеграция AppCenter с VisiBroker и AppServer обеспечивает создание высоконадежной единой информационной среды предприятия.
AppCenter позволяет администраторам и менеджерам информационных систем идентифицировать не только все индивидуальные компоненты, но и их рабочие характеристики, а также взаимозависимости объектов и расширенные параметры их взаимодействия. Архитектура AppCenter базируется на репозитарии конфигураций приложений, объектов и служебных сервисов системы. Агентская среда AppCenter обеспечивает централизацию процессов развертывания, эксплуатации и мониторинга прикладной инфраструктуры в целом, а также отдельных ее компонентов. Используя описание взаимосвязей, хранящихся в репозитарии конфигураций приложений, AppCenter запускает все необходимые объекты независимо от того, на какой машине они располагаются, и делает это в нужном для правильной работы приложения порядке. Такая возможность существенно упрощает задачу управления распределенными приложениями, повышая продуктивность работы эксплуатационного персонала, поскольку позволяет ему сконцентрироваться на критических оперативных вопросах.
|
|
Поддержка разработчиков
Вorland предоставляет пользователям AppServer, VisiBroker и других программных продуктов различные возможности по получению технической поддержки и консалтинговых сервисов. Кроме того, разработчикам доступна русская документация по AppServer (для версии 4.1), которая в электронном виде доступна по адресу http://www.borland.ru/appserver/. Разработчики также могут обращаться в консалтинговые службы Borland (http://www.services.borland.ru/), где в настоящее время работают российские эксперты высочайшего уровня, широко известные читателям по своим книгам, статьям и выступлениям на семинарах и конференциях.
КомпьютерПресс 6'2001
