Полшага от распределенных вычислений к серверам приложений
Интернет и распределенные вычисления
Введение
Всего несколько лет назад об Интернете никто и не слышал, а верхом компьютерных технологий считались локальные сети. Постепенно цифровые технологии менялись, а с ними менялся и окружающий мир. Сеть с маленькой буквы превратилась в «Сеть» с большой, все чаще стали говорить о сетевом образе жизни и сетевом ведении бизнеса. Из предоставляемых сетевых ресурсов после доступа к файлам и иной хранящейся на компьютерах информации самым желанным ресурсом стали сами вычислительные мощности процессора. В навязчивую идею превратилась мечта соединить вычислительные силы всех компьютеров, объединенных в Сеть, и получить таким образом самый мощный суперкомпьютер. Но, как говорится, к великой мечте надо идти постепенно, маленькими шагами. Поэтому, несмотря на гигантские темпы развития компьютерной индустрии, развитие распределенных вычислений носило неторопливый, но выверенный и вдумчивый характер.
Еще в начале 90-х годов великие мужи от индустрии объединили свои усилия, создав консультационную группу OMG (Object Management Group), и начали размышлять о том, как должна осуществляться связь между двумя вычислительными процессами, выполняющимися на разных машинах. В результате за эти годы появилась спецификация CORBA, по сути являющаяся стандартом способа организации распределенных вычислений в гетерогенной среде. Антагонисты Microsoft и поклонники Unix воспевают спецификации CORBA уже давно. Но только в последнее время программная индустрия стала предлагать растущие как грибы после дождя готовые решения, соответствующие этим спецификациям.
В первую очередь внедрение распределенных вычислений потребовало распространения сети Интернет и начала активной реализации «умных» Web-серверов, динамически формирующих внешнее представление сайта, а то и обменивающихся информацией с другими такими же «умными» серверами. Второй причиной развития технологии распределенных вычислений явилась суровая необходимость объединить в единое целое программные наработки компаний и предприятий, которые были сделаны за годы компьютерной революции. Разные компьютерные платформы, совершенно разнородные программные продукты, активно работающие и влияющие на текущий бизнес, могло объединить только чудо. Таким чудом стали распределенные вычисления и объектно-ориентированное проектирование информационных систем.
Сначала речь шла о переходе с программирования на уровне программ на программирование на уровне отдельных объектных компонентов. Хотя активные споры о том, что же такое компонент, продолжаются до сих пор, можно с уверенностью определить компонент как отдельный программный модуль — программу, которая общается с внешним миром через интерфейсы представляемых объектов со своими методами и порядком их вызова. Как и обычные объекты в языках программирования, компоненты создаются в операционной системе по мере необходимости, делают свое дело, а затем безжалостно уничтожаются. Имея набор работающих компонентов, из них, как из готовых кирпичиков, можно строить само приложение. А «кирпичики» можно создавать самостоятельно, или купить готовые модули у сторонних разработчиков.
После успешного завершения разделения на объектную структуру в виде компонентов в рамках одного компьютера встал вопрос о том, как разнести эти работающие вместе компоненты по разным компьютерам. Кто-то стал задумываться о создании собственных интерфейсов, а кто-то — о реализации в собственных продуктах уже готовой к тому времени спецификации CORBA. В этот момент компания Sun Microsystems и представила свое видение распределенных вычислений в виде спецификаций JavaBeans.
 |
|
Сервер приложений
По мере формулирования нужд индустрии выяснилось, что под распределенными вычислениями подразумевают скорее удаленные вычисления, когда выделенный сервер предоставляет интерфейс и доступ к запуску на нем необходимых программ-компонентов. Да и корпоративная ориентация на клиент-серверные архитектуры сразу перестроила модель распределенных вычислений по образу и подобию того, как раньше строилась работа клиентских приложений с удаленным сервером баз данных. В результате «тонкий» клиент осуществлял визуальное представление интерфейса программы, а вся логика и основные операции осуществлялись при обращении к удаленному серверу с находящимся на нем приложением.
Основной проблемой стала поддержка коммуникационной среды между установленными на сервере компонентами и вызывающими их клиентскими приложениями. Взаимодействие между компонентами на одном и том же компьютере также требовало единой среды, позволяющей не ограничиваться рамками одного компонента, а объединять вместе некоторые из них в одно выполняющееся на сервере приложение. Именно такой средой для жизни компонентов и стали программные продукты, получившие название «сервер приложений».
Помимо поддержки коммуникационных протоколов для связи с внешним миром, откуда происходит управление работающими компонентами, современный сервер приложений должен взять на себя заботу об оптимизации работы самого компонента и обеспечить поддержку «джентльменского набора» операций, практически всегда востребованных при создании распределенной вычислительной системы. Так, к функциям сервера приложений были добавлены операции по поддержке работы с базами данных и построению отказоустойчивых систем, способных функционировать даже тогда, когда часть компьютеров в сети выходит из строя.
Чтобы не быть голословными, посмотрим, что именно предлагают производители программного обеспечения в коробках с названием «сервер приложений». В качестве примера возьмем столь любимый на Уолл-стрит Enterprise Application Server (EAServer) от компании Sybase. Этот продукт является результатом многолетних исследований компании в области распределенных вычислений, активно развиваемых и ранее в рамках линейки продуктов OpenServer. Помимо солидной истории практического использования EAServer в информационных системах, программный продукт обладает уникальной поддержкой всех современных стандартов, предъявляемых к серверам приложений, и всех необходимых функций для быстрого создания масштабируемой вычислительной системы. И уж конечно, EAServer поддерживает спецификации CORBA и J2EE.
|
|
Клиентский доступ
Начнем с методов доступа к серверу. Раз уж мы выделили специальный сервер для выполнения наших операций, хотелось бы и достаточной универсальности в методах доступа к нему. И здесь EAServer в первую очередь предлагает доступ по протоколу IIOP (Internet InterORB Protocol), являющемуся стандартным протоколом доступа к удаленным объектам в соответствии с требованиями спецификации CORBA. Без поддержки этого протокола практически невозможно связать в единое целое компоненты, выполняющиеся на разных компьютерах и в разных операционных системах. Прежде всего это касается многообразия различных версий UNIX, широко представленных на рынке серверов и платформ для корпоративных вычислений. Но и любимая народом платформа Windows не забыта: в комплекте поставки EAServer имеет полный набор библиотек для доступа к серверу по протоколу IIOP из любого Windows-приложения.
Помимо стандартного протокола вызова удаленных компонентов, EAServer поддерживает
вариант доступа и по фирменному протоколу компании Sybase TDS (Tabular Data
Stream), который она использует для обмена данными со своими СУБД. Поддержка
этого протокола позволяет любому клиенту, способному вызвать хранимую процедуру
в Sybase-совместимой базе данных, осуществить таким же образом и вызов методов
компонента. Учитывая доступность и распространенность всевозможных драйверов
для работы с базами данных, такой способ позволяет работать с сервером приложений
даже старому клиентскому приложению, ранее работавшему только с самой базой
данных. В равной степени использование протокола TDS позволяет осуществлять
вызов методов компонентов даже из хранимых процедур вашей БД.
Поклонников Windows может возмутить отсутствие поддержки стандарта удаленного вызова компонентов DCOM, но как его поддерживать, если сервер может быть запущен в операционной системе UNIX, которая о стандартах Microsoft и знать ничего не знает? Для таких клиентов компания Sybase предлагает специальную ActiveX-заглушку, устанавливаемую на клиентском компьютере и позволяющую через COM-интерфейс осуществлять вызов компонентов EAServer с помощью протокола IIOP.
Ну а если говорить обобщенно о протоколе IIOP, то откуда можно по нему осуществить доступ? Как уже говорилось, в состав EAServer входят бинарные библиотеки для вызова IIOP из любой программы, написанной на языках С или С++. Сами библиотеки зависят от платформы, для которой работает продукт, и помимо платформы Microsoft/Intel поддерживают подавляющее большинство UNIX-платформ. Кроме бинарных библиотек существуют библиотеки для вызова IIOP из Java-программ, а также имеется поддержка для программ, созданных в инструментальной среде компании Sybase PowerBuilder.
Перечисленные варианты клиентского доступа покрывают все мыслимые способы построения клиентских программ, но главное в том, что использование корпоративного стандарта — протокола IIOP — для обращений к серверу гарантирует возможность использования любого продукта третьих фирм, предназначенного для работы с удаленными объектами по стандарту CORBA.
|
|
Компоненты
Теперь давайте посмотрим, с какими компонентами сервер приложений EAServer позволяет осуществлять работу. Среди стандартов на программные компоненты существуют всего две спецификации, реально распространенные в индустрии. Это работающий на Intel/Microsoft стандарт ActiveX и независимый от конкретной операционной системы и вида процессора стандарт JavaBeans от компании Sun Microsystems. И если поддержка ActiveX обусловлена достаточным количеством имеющихся наработок для платформы Windows, то поддержка JavaBeans уже стала пропуском в райские кущи завтрашнего дня и помимо машинонезависимости сулит еще много других преимуществ. Главное среди них — совместимость с тысячами уже работающих и поставляемых на рынок готовых решений, действительно позволяющих использовать самые современные методы ведения бизнеса и создания инфраструктуры предприятия. Поэтому EAServer в равной степени поддерживает и все имеющиеся наработки как для платформы Windows, так и для большинства использующихся UNIX-платформ.
Тут бы самое время опять вспомнить столь любимую индустрией спецификацию CORBA, но, увы, на вопрос, как создавать компоненты, она ответа не дает. Основные спецификации CORBA касаются только вопроса сетевого взаимодействия удаленных компьютеров. Но если иметь в виду, что такое взаимодействие EAServer сервер предоставляет в виде поддержки протокола IIOP, то получается, что любой подключенный в EAServer компонент автоматически становится CORBA-компонентом!
Посмотрим, что же помимо уже перечисленных ActiveX и JavaBeans поддерживает EAServer. Здесь почти такое же разнообразие, как и среди возможностей клиентского доступа. Компонент можно создать на языках С и С++ с использованием специальных библиотек. Можно также написать компонент на языке PowerBuilder, сохраняя машинонезависимость Р-кода и гораздо большую наглядность приложения, чем на языке Java. В конце концов, компонент можно создавать и на языке Java, не стараясь соблюсти все требования компонентной спецификации JavaBeans. Но и это еще не все! Если у вас имеются старые наработки в виде хранимых SQL-процедур, то их тоже можно оформить в виде компонента. Аналогичным образом в недра EAServer можно подключить мэйнфрейм системы компании IBM, бизнес-объекты программы SAP R/3 и осуществить интеграцию с продуктами таких компаний, как PeopleSoft, Clarify и Siebel1.
|
|
А что еще?
Итак, мы создали компоненты, написали клиентскую программу для удаленного к ним доступа. Нужно ли разработчику что-то еще для полного счастья? Конечно! Ведь отдельно взятых компонентов в реальной жизни не существует! Они производят обмен информацией с базами данных, с другими компонентами. И сервер приложений обязан взять на себя контроль за этим процессом на себя. Если обмен информацией происходит только с одной базой данных, то она сама предоставит транзакционный контекст, позволяющий обеспечить целостность обрабатываемой информации. А если сервер приложений работает с несколькими базами данных, да еще и через промежуточные компоненты? Вот здесь и приходит на помощь сервер приложений, обеспечивающий целостность информации не только на уровне отдельной базы данных, но и в целом во всей информационной системе, подключенной к серверу. EAServer использует для этого встроенный координатор транзакций OTS/XA, также являющийся стандартным для корпоративных вычислительных сред. Исключительно для платформы Windows поддерживается и Microsoft DTC (Distributed Transaction Coordinator), поставляемый с Microsoft SQL Server2.
Второй стороной работы распределенной информационной системы является надежность.
Даже самые надежные программные продукты ничего не могут сделать, если из строя
выходит сам компьютер, что иногда все-таки случается. А вот EAServer позволяет
успешно продолжить работу и в таком случае. Конечно, для этого одним компьютером
не обойтись — необходимо установить как минимум резервный сервер на случай выхода
из строя основной машины. А можно построить целый кластер из соединенных параллельно
машин, готовых прийти на помощь друг другу в случае сбоя. Да и производительность
такого кластера будет пропорциональна количеству работающих в нем компьютеров.
При этом EAServer автоматически будет управлять загруженностью машин, следя
за тем, чтобы ресурсы кластера не простаивали.
|
|
Волшебный аромат кофе
Высокая мода существует во всем — и в одежде, и в компьютерной индустрии. Только в вычислительной технике мода называется стандартами и позволяет различным разработчикам согласовывать свои усилия и не тратить драгоценное время на изобретение очередного велосипеда. Таким современным «модным стандартом» стала спецификация J2EE (Java 2 Enterprise Edition) компании Sun Microsystems для построения компонентной архитектуры на языке Java. Действительно, темпы внедрения языка Java на корпоративный рынок просто поражают, хотя этому легко найти объяснение. Современные виртуальные Java-машины показывают гораздо большую производительность, чем их предшественники, а возможность исполнения одного и того же кода и на персональном компьютере, и на дорогом многопроцессорном UNIX-сервере позволяет экономить массу ресурсов, когда возможности используемой аппаратной платформы подходят к концу и необходим переход на более мощную компьютерную базу.
Помимо дальнейшего развития компонентной архитектуры JavaBeans, спецификация J2EE определяет и остальные части внутреннего окружения сервера приложений, в том числе систему обмена сообщениями, обработки почты и контроля за распределенными транзакциями в базе данных. Четкая и понятная спецификация для дальнейшего развития внутренней структуры сервера приложений оказалась настолько к месту, что совместимость с J2EE сегодня декларируют все кому не лень. Автор лично присутствовал на презентации одной весьма популярной в России компании, которая заявляла о совместимости их сервера с J2EE, хотя на сайте корпорации Sun об этом не говорилось ни слова. С этой точки зрения EAServer совместим с J2EE на все 100%. Мало того, что сервер успешно выполнил все тесты компании Sun на совместимость со спецификацией, — эти тесты были проверены инженерами компании Sun Microsystems, о чем, и был выдан соответствующий сертификат.
|
|
Интернет и распределенные вычисления
Помимо внутрикорпоративных систем спрос на серверы приложений особенно велик при создании крупных Интернет-сайтов или порталов, большая часть информации на которых должна динамически генерироваться и обрабатываться на самом Web-сервере. Появление «тонких» клиентов, представляющих собой только браузер, установленный на машине пользователя, послужило дополнительным толчком к распространению серверов приложений. Поэтому неудивительно, что большинство понятий в области распределенных вычислений так или иначе связаны с Web-хостингом и динамическим формированием HTML-страниц. Спецификация J2EE тоже имеет в своем составе стандарты создания Java Server Pages (JSP) и сервлетов, которые описывают порядок динамического формирования содержимого сайта на языке Java.
EAServer поддерживает и технологию JSP, и технологию сервлетов, а также свою старую разработку PowerDynamo, являющуюся серверным вариантом языка JavaScript. Главное, что в EAServer уже встроены Web-сервер и вся необходимая поддержка для хостинга динамического сайта. В результате разработчик получает возможность использовать уже имеющийся Web-сервер, интегрированный в сервер приложений, или задействовать внешний Интернет-сервер, выбрав его среди популярных на рынке программ.
Все перечисленные технологии несут единую основную нагрузку — совместить HTML-код дизайна сайта с информацией, обработанной на сервере приложений. Возможности протокола HTTP позволяют построить любой, сколь угодно сложный визуальный интерфейс на клиентской машине. Поэтому крупные и мелкие компании стараются постепенно привести все свои информационные системы к единому интерфейсу, доступному и внутри корпорации, и за ее пределами по сети Интернет. Ядром такой информационной системы следующего поколения, конечно, остается сервер приложений.
Кстати, одной из самых привлекательных особенностей EAServer является его готовность
к построению Интернет-решений, что давно было подмечено западными компаниями.
Сейчас на базе EAServer работают порталы таких крупных компаний, как America
Online, Federal Express и др.
|
|
Что выбрать?
Перечисленные возможности EAServer компании Sybase радуют разнообразием своих возможностей и универсальным подходом, предлагаемым проектировщику. Реализация сервера имеется и для платформы Windows NT, и для версий UNIX на платформах Sun, AIX, HP… В ближайшее время ожидается версия сервера и для самого демократичного UNIX’a всех времен и народов — Linux. Однако далеко не все имеющиеся на рынке продукты обладают таким же полным набором совместимости со «всем и вся». Большинство компаний ограничиваются обычно поддержкой технологии JavaBeans (хотя соответствие спецификациям J2EE уже принято считать хорошим тоном). Отрадно, что теперь никто не оспаривает непререкаемость поддержки CORBA. Это по крайней мере оставляет возможность привлечь на помощь продукцию других фирм, если вдруг оказалось, что выбранный вами сервер приложений не отвечает всем вашим требованиям. Главное, что достаточно спокойный мир клиент-серверных приложений дополнился третьим слоем, состоящим из серверов приложений, которые берут на себя непростую задачу объединения не только отдельных фрагментов информационных систем предприятия, но и всех нас в рамках сети Интернет.
С автором этой статьи можно связаться по тел.: (095) 797-4774, e-mail: dmitriev@sybase.ru
КомпьютерПресс 4'2001
