Сегодня интерес к серверам приложений (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. Это позволяет рассматривать такие серверы приложений в качестве критически важного элемента прикладной инфраструктуры предприятия.
Безопасность распределенных вычислений
 Tехнология middleware |
Обеспечение защиты информации является ключевым требованием для всех современных информационных систем. Borland AppServer предлагает средства обеспечения безопасности, включающие всестороннюю поддержку SSL ( SSL - Secure Sockets Layer ), работу через межсетевой экран и развитые механизмы аутентификации и авторизации.
Например, для аутентификации AppServer и Borland Security Service поддерживают механизмы user/password с хранением учетной информации либо на сервере приложений, либо путем использования существующих методов (Windows NT/SAM, UNIX/NIS). Еще один, весьма удобный и популярный тип аутентификации как клиента, так и сервера в Borland Security Service - применение сертификатов Х.509 с поддержкой инфраструктуры PKI и протокола LDAP ( LDAP - Lightweight Directory Access Protocol ) . Для поддержки механизмов авторизации в 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), добиваясь максимальной продуктивности и высокого качества создаваемого программного обеспечения.
 Рис. 7. Интеграция средств Borland AppServer c JBuilder Enterprise |
 Рис. 8. Синхронизация модели и проекта J2EE-систем в Rational Rose с использованием JBuilder Rose Link |
Весной 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 без остановки серверов, контейнеров и сервисов, обеспечивая непрерывную работу в операционном режиме 24x7.
 Рис. 9. Консоль Borland AppServer |
Консоль может использоваться для просмотра не только атрибутов EJB-контейнера, но и параметров его производительности. Параметры производительности могут быть полезны, например, для определения времени, затрачиваемого контейнером для выполнения активации объектов или организации вызова удаленного метода. Эта информация помогает обнаружить проблемы в сети (на пример, если контейнер тратит большую часть времени на организацию удаленных вызовов, а не на выполнение кода методов компонентов). Пользователь может выбрать различные форматы отображения такой информации - графики, двух и трехмерные гистограммы, таблицы.
Более функциональный, чем консоль AppServer, Borland AppCenter (рис. 10) является уникальным инструментом менеджмента и мониторинга распределенных решений на основе технологий J2EE и CORBA. Интеграция AppCenter с VisiBroker и AppServer обеспечивает создание высоконадежной единой информационной среды предприятия.
 Рис. 10. Консоль Borland AppServer |
AppCenter позволяет администраторам и менеджерам информационных систем идентифицировать не только все индивидуальные компоненты, но и их рабочие характеристики, а также взаимозависимости объектов и расширенные параметры их взаимодействия. Архитектура AppCenter базируется на репозитарии конфигураций приложений, объектов и служебных сервисов системы. Агентская среда AppCenter обеспечивает централизацию процессов развертывания, эксплуатации и мониторинга прикладной инфраструктуры в целом, а также отдельных ее компонентов. Используя описание взаимосвязей, хранящихся в репозитарии конфигураций приложений, AppCenter запускает все необходимые объекты независимо от того, на какой машине они располагаются, и делает это в нужном для правильной работы приложения порядке. Такая возможность существенно упрощает задачу управления распределенными приложениями, повышая продуктивность работы эксплуатационного персонала, поскольку позволяет ему сконцентрироваться на критических оперативных вопросах.
Вorland предоставляет пользователям AppServer, VisiBroker и других программных продуктов различные возможности по получению технической поддержки и консалтинговых сервисов. Кроме того, разработчикам доступна русская документация по AppServer (для версии 4.1), которая в электронном виде доступна по адресу http://www.borland.ru/appserver/. Разработчики также могут обращаться в консалтинговые службы Borland, где в настоящее время работают российские эксперты высочайшего уровня, широко известные читателям по своим книгам, статьям и выступлениям на семинарах и конференциях.