Для чего используются сервера приложений. В чем разница между сервером приложений и веб-сервером? Что такое css

Сначала были Файл-сервер и Принт-сервер, довольно быстро к ним добавился Почтовый сервер. Не успели мы как следует привыкнуть к Web-серверам, как судьба подкидывает нам новые испытания - изволь осваивать Сервер Приложений. Особая проблема возникает при переложении понятия на русский язык. Тут уже путаница становится просто невообразимой. Искушенный читатель может с досадой воскликнуть - «Э! Да что же тут нового? Это же обычная многозвенка: сервер приложений, сервер базы данных и клиент!» - и прекратить чтение. Однако, Сервер Приложений - это Федот, да не совсем тот.

Итак, начнем по порядку, чтобы и не столь искушенный читатель понял, что имеется в виду. Предмет наших размышлений - это Application Server или Сервер Приложений. Ныне модно в качестве предисловия давать рекламу наоборот - перечислять то, чего в написанном нет; то ли из ложной скромности, то ли следуя завету Микеланджело: убирать все лишнее. Поэтому вы не найдете в этой статье серьезного доказательного сравнения технических реализаций Серверов Приложений, описания методов и приемов работы с этими реализациями, примеров файлов, листингов и кусков кода - приведен лишь список источников, в которых можно все это отыскать. Здесь же займемся более общими, но не менее увлекательными вопросами - что такое Сервер Приложений, зачем это нужно, как это покупать и выбирать и как с этим работать. Предвижу недовольство читателей, которые убеждены в том, что их не пускают на «кухню» и, следовательно, в приготовленном кушанье будет намешано неизвестно что. Приведу краткие соображения, почему следует читать и писать не только сугубо технические статьи. Прежде чем готовить еду, надо определить что - суп или гарнир, легкий ужин или обед для званых гостей, надо составить меню, заготовить продукты, выработать план изготовления, а уже потом приступать к поварскому ритуалу. Какой этап важнее - на этот предмет существует известная сказка, в которой плотник, портной и кукольник спорят, кому должна принадлежать сделанная ими кукла. Насколько я помню, в сказке побеждал кукольник, поскольку именно он вдохнул в куклу жизнь. В этом смысле таким волшебником несомненно является программист-разработчик. Нимало не преуменьшая его роль, я все-таки замечу, что современные программные приложения всегда плод коллективной работы. Поэтому провал или даже неудовлетворительное выполнение любого промежуточного этапа могут безнадежно загубить все дело.

Но, довольно реверансов. Нас ждет Сервер Приложений, которому просто не терпится убедить вас в том, что без него не обойтись.

Как ни грустно опять обращаться к знакомой всем заинтересованным лицам истории компьютерных технологий, без этого Сервер Приложений предстанет перед нами бродягой без роду и племени. Но я постараюсь быть краткой, тем более что истории то всего лет 50, правда, очень стремительных. Основные этапы этой истории приведены на рис. 1.

Первая эра - эра эксклюзивного «монолита», когда компьютерные программы, или потом, пакеты программ, выполнялись на одном компьютере. Особого выбора у потенциальных потребителей программных продуктов тогда не было - или сам разрабатывай, или заказывай у опытных людей. Тогдашние операционные системы не баловали богатством возможностей - работает приложение на компьютере - и хорошо. Оно могло работать годами, выполняя раз навсегда закрепленные функции, и все были довольны. Это время часто называют и «эрой мэйнфреймов», хотя именно мэйнфреймы подошли вплотную к «тихой революции». От них появилась возможность приставить к одному серверу несколько «глаз» - терминалов, которые позволили плавно перейти в «клиент-серверную эру». Вот тут то и появляется служака «сервер». Сервер работает, служит, выполняя задания его величества клиента. Клиент от простенького «застенчивого» терминала вырастает до важного и значительного повелителя. Нынешний революционный момент характеризуется тем, что серверы не могут, а клиенты не хотят существовать по-старому. Первые не могут справиться с обилием поставленных перед ними требований, а вторые недовольны качеством обслуживания их запросов. Выход - в дальнейшей специализации. То, что пыхтя и отдуваясь выполняет несчастный сервер, теперь будет распределено на множество серверков - компонентов, каждый из которых успешно выполняет свою функцию. В такой компании клиенты превращаются в равноправные компоненты, чья задача - представительство функциональных сотоварищей (других компонентов) для пользователя, сидящего перед дисплеем.

Раз уж мы ввели строительный термин - монолит, то приведем строительно-архитектурную параллель. Первая - монолитная эра, эра дольменов и кромлехов, отдельных решений, автоматизирующих конкретные производственные задачи заказчика. Опыта еще мало - каждое сооружение в некотором смысле произведение искусства. Вторая эра - однотипные поселения, каждое их которых характеризуется зaмком (сервером) и постройками попроще вокруг (клиентами). И если простые постройки не представляют большой архитектурной ценности, то замки - решения штучные и дорогостоящие. А переходим мы в эру массовой застройки, когда «строительство» программных приложений поставлено на поток. И сколько бы мы ни ругали такую застройку, именно этот способ позволяет обеспечить жильем - программными приложениями, всех желающих за разумную цену и в реальные сроки.

Типовые современные дома обычно строятся из блоков или панелей. Так и современные программные приложения строятся или, скорее, будут строиться из компонентов. (Компонент - самостоятельный программный продукт, поддерживающий объектную парадигму, реализующий отдельную область бизнес-логики и умеющий взаимодействовать с другими компонентами с помощью открытых интерфейсов.) Такая технология позволит ответить на самые острые проблемы компьютерного мира - сокращение времени разработки программного приложения, облегчение процесса внедрения и поддержка гибкости внедренного решения. На рис. 2 изображены этапы жизненного цикла программного приложения.

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

Под лозунгом «Быстрее, легче и гибче» и создаются современные бизнес-компоненты. Преимущества подобного подхода можно выразить в длинном списке: масштабируемость, стабильность, управляемость, настраиваемость, гибкость, переносимость, возможность многократного использования. Но, к сожалению, чудес в жизни не бывает и, если сложностей и неурядиц убыло в одном месте, то в другом они как раз прибавились. Для того чтобы компоненты умели взаимодействовать, необходимо развитие «клея» - промежуточного программного слоя.

Итак, если со стороны бизнеса все красиво, как на затейливом персидском ковре, то зато на изнанке - уйма всяких узелков и зацепок. Последние годы мировое программное сообщество усиленно пытается внести порядок в эту изнанку, в чем, надо сказать весьма преуспело. Основная возможность здесь - стандартизация компонентов, приведение их к единой природе. Блоки здания должны быть сопрягаемы. Нити ковра должны быть из близких материалов. Идея здесь достаточно проста - внешние интерфейсы компонентов должны быть описаны в едином стиле - на одном и том же языке. Поэтому два известных на сегодняшний день стандарта, CORBA и COM+ создали свои варианты IDL - Языка Описания Интерфейсов. CORBA, COM+ и технология Java, которая, естественно, использует для описания интерфейсов язык Java, предлагают близкие подходы к методу взаимодействия компонентов. На основе описания внешних интерфейсов создаются прокси (заместители) для клиента и сервера, которые позволяют им связываться друг с другом в реальном времени. Прокси для клиента принято называть стабом, а прокси для сервера - скелетоном. (Мы договорились - я не претендую на изложение технологий, а только даю краткий взгляд на них. Поэтому, в частности, не касаюсь возможностей динамического взаимодействия компонентов в технологии CORBA, когда внешние интерфейсы не определены на момент компиляции системы и появляются дополнительные динамические элементы.)

После стандартизации интерфейсов, мировое компьютерное сообщество перешло на следующий уровень стандартизации - самих компонентов. Из рис. 3 понятно, что я имею в виду под следующим уровнем стандартизации - все дальше от «железа», все ближе - к пользователю. В технологии CORBA это:

• ССМ (CORBA Component Model)- компонентная объектная модель, компонентное развитие модели бизнеса ВОМ - Business Object Model;
• BOCA (Business Object Component Architecture) - принципы архитектуры компонентных систем, развитие OMA (Object Management Architecture) на вышележащий уровень стандартизации;
• CDL (Component Definition Language)- язык определения компонентов, развитие IDL.

Разработка этих стандартов продвигается, правда, не так быстро, как хотелось бы всем заинтересованным сторонам. Но признанным героем на поле стандартизации компонентов стала технология компании Sun - Enterprise Java Beans (EJB). Возможно причина ее успеха в том, что в «семейном кругу» одного языка программирования намного проще решить вопросы взаимодействия. Тем более языка молодого и резвого, который многие проблемы, такие как вызов удаленных методов (RMI - Remote Method Invocation), умеет решать сам. Не иcключено, что универсальные цели консорциума OMG, развивающего технологию CORBA, - объединить компоненты, написанные на разных языках программирования, функционирующие на разных системах и разных компьютерах в разных точках земного шара, являются в данном случае некоторым тормозом. В дальнейшем мы увидим как две технологии, сомкнувшись, отбросив амбиции, дают замечательный результат на радость всем заинтересованным сторонам.

Что же такое этот «бин» (beаn - боб) и почему, стремительно выскочив как джин из бутылки в компьютерный мир, он уже завоевал такую популярность? Если перевести определение Sun как можно ближе к оригиналу - то «это модель для создания и развертывания серверных компонентов многократного использования, написанных на языке Java.» Продолжим вместе с Sun расплетать косу этого определения, - «компоненты - это заранее разработанные куски программного кода, которые могут быть установлены в работающие прикладные системы». Если классы Java образуют компонентную модель для проектирования приложений в технологии Java, то Java Beans логически развивает эту модель на следующем уровне интеграции создания автоматизированных систем и абстрагирования от процесса программирования - стадии внедрения. По сути, это переход от разработки приложения под заказ из готовых программных компонентов к сборке из готовых ЕJB действующих компонентов. Если раньше дома складывали из кирпичей, то теперь - из комнат-секций. Cлово Enterprise в названии Enterprise Java Beans означает новую ступень технических задач, стоящих перед программными приложениями. Такие задачи привычны для приложений уровня Предприятия: поддержка распределенности, службы именования, транзакций, безопасности, уведомлений-сообщений, долговременного хранения, и т.д. Неудивительно, что этот список напоминает список Служб технологии CORBA.

С точки зрения разработки, EJB представляют собой Java-классы специального типа вместе с описателем-паспортом бина и параметрами среды функционирования, которые бин умеет обрабатывать. Описатель бина (Deployment Descriptor) в свою очередь представляет собой XML-файл, в котором содержатся правила, связанные с управлением бином, например, права доступа пользователей к бину. Несколько бинов могут объединяться, образуя приложения, Java-апплеты и новые бины.

Рис. 4. Контейнер Enterprise Java Beans

По технологии EJB бобы-бины размещаются в стручке - контейнере (рис. 4) На контейнер возложены обязанности по защите бинов и поддержке их взаимоотношений с внешним миром: регистрация-прописка объектов, обеспечение для них внешних интерфейсов, создание и разрушение реализаций этих объектов, охрана безопасности, управление их состояниями и координация транзакций. В технологии не определено, как конкретно должен быть реализован контейнер. Это могут быть как многопоточные процессы на отдельном сервере, в которых выполняются бины, так и законченные программные приложения, которые можно переносить или распределять между серверами и/или процессами. Клиентские бины обрабатываются внутри виртуальных контейнеров, таких как Web-страницы, формы, составные документы, и т.д.

В технологии определены два основных типа бинов. Session Beans - сеансы клиент-серверного взаимодействия отрабатывают действия клиента, например, запись в базу данных, выполнение вычислений, и т.д. Это окна клиента в мир программных приложений. Они, в свою очередь, также бывают двух типов:

• Stateless session - не умеют сохранять свое состояние и существуют только на протяжении текущего сеанса. В случае сбоя сеанс не может быть восстановлен;
• Stateful session - сохраняют свое состояние; сеанс может быть восстановлен.

Entity Bean - компоненты объектного представления данных, размещаемых в хранилище. Entity Bean транзакционны и восстанавливаемы. Каждая их реализация имеет уникальную метку, называемую «первичным ключом» (Primary Key) по аналогии с таблицами баз данных. В свою очередь эти бины делятся на две группы по способу определения где, в каком хранилище и как хранятся данные:

• Bean-Managed Persistence - самостоятельные бины, управление хранением осуществляется на уровне бинов;
• Container-Managed Persistence - «опекаемые» бины, чьим хранением заправляет контейнер.

Кроме класса, реализующего функциональность бина, в него входят два обязательных класса, реализующие два типа интерфейсов:

• Home Interface - доступ к «домашним» службам бина, таким как начало или отбой для Session Bean или поиск Entity Bean. Этот интерфейс реализует все службы жизненного цикла компонента и позволяет контейнеру управлять и руководить его поведением;
• Remote Interface - доступ к бизнес-службам бина.

Клиентские приложения общаются с бинами через контейнер, который открывает наружу оба интерфейса бина: Home и Remote. С помощью первого открывается сеанс или находится нужный бин, а с помощью второго - осуществляется отработка действий клиента в Session или транзакционная механика обработки Entity.

Итак, повторим идею технологии с прикладной точки зрения. Прикладная бизнес-логика приложения делится на изолированные бизнес-объекты, каждый из которых реализуется в виде EJB. Они устанавливаются на Сервере Приложений или EJB Сервере и реализуют запрашиваемую логику для клиента (локального или удаленного). Давайте прямо сейчас, при первом появлении понятия Сервер Приложений в технологии Java, развеем непонимание, о котором уже говорилось в начале статьи. Написав оба слова, составляющие понятие, с заглавных букв, мы магическим образом преобразовали сервер приложений, реальную машину из корпуса, начинки и кабелей, в программное приложение.

Обратимся вновь к интерпретации Sun. Под Сервером Приложений в технологии Java понимается программное приложение, обеспечивающее оптимальную среду для выполнения EJB. Сервер Приложений занимается «коммунальным хозяйством» дома - программной системы. На его руках надзор за системными ресурсами, такими как процессы, потоки, память, связь с базами данных, сетевые отношения, выравнивание загрузки распределенных узлов. Кроме этого важнейшая обязанность Сервера Приложений заключается в предоставлении cle;, компонентам.

Еще раз хочу подчеркнуть, что технология EJB, впрочем, как и технология CORBA не предоставляет готовые программные решения - контейнеры, Сервера Приложений, а только стандарты на такой тип программного обеспечения.

Стандарты - единственная возможность обеспечить некоторый порядок в бурно развивающемся компьютерном мире. Стандарты необходимы всем трем заинтересованным сторонам в области информационных технологий: разработчикам, потребителям-заказчикам и промежуточному звену - консультантам, интеграторам, продавцам. Первым - для поcтавки на рынок конкурентоспособных, жизнестойких решений, вторым - как средство борьбы с «зоопарком» программных систем, третьим - как возможность строить гибкие, интегрированные программные среды для своих заказчиков.

Стандарты продолжают захватывать все новые области информационных технологий. Но, если в сетевых технологиях стандарты полностью прижились, то в области программных приложений они еще только набирают силу. Понятны опасения специалистов использовать в собственных решениях «неправильный» стандарт, который зачастую, невзирая на грамотные технические решения, заложенные в его основу, не идет дальше прекрасных инициатив и не получает развития. Выбирая дорогу, всегда есть опасность оказаться в тупике. Именно поэтому стоит внимательно читать указатели (в смысле дорожные знаки) и прислушиваться к мнению мирового сообщества. Серверы Приложений уже сейчас имеют реализации от большинства крупных производителей программных систем (компании Inprise, Oracle, Sybase, Sun, BEA, Iona, IBM). Кроме того, в данной области архитектуры программных приложений пока не появилось ни одного достойного конкурента. Так что стиль пока единственный - Сервер Приложений.

Если посмотреть на Серверы Приложений глазами конечного пользователя, то они представляют собой основные несущие конструкции сооружения под названием многозвенная распределенная компонентная программная система. Именно Серверы Приложений поставляют бизнес-компоненты и обеспечивают необходимый уровень системных служб для этих компонентов, т.е. всю коммунальную систему жизнеобеспечения. Приложения, которые наш Сервер предоставляет клиентам, могут располагаться где угодно, причем эти приложения могут даже не знать, где хранятся данные, с которыми они работают - на каком сервере и в какой базе данных. Для клиентов Сервер Приложений открывает и закрывает сеансы. Для приложений - позволяет настраивать системные службы, из которых важнейшими являются служба долговременного хранения, политика хранения компонентоа Entity Beans, служба транзакций и служба безопасности.

«А надо ли городить огород?, - спросит недоверчивый читатель. - Зачем мне такое дополнительное ПО для моего сугубо конкретного программного приложения?»

Огород, может быть, городить и не надо, а обеспечить газом, электричеством и горячей водой наш блочный дом, программное приложение - необходимо. Да и надежный кодовый замок на входной двери не помешает. Конечно, можно предоставить решать эти проблемы самим жильцам. Пусть каждый в одиночку кипятит воду и укрепляет входную дверь. Тогда уж лучше просто влезть на дерево (я никоим образом не имею в виду службу каталогов NDS) и кушать бананы (не путайте с Baan).

Чтобы постройка программного приложения не напоминала возведение Вавилонской башни, в технологии EJB расписано, кто именно должен принимать участие в проекте. Комплексная бригада строителей здания состоит, по представлению компании Sun, из следующих профессионалов.

Архитектор

Поставщик серверной платформы (EJB Server Provider) - специалист в области распределенной платформы и служб. Он предоставляет инфраструктуру разработки и среду выполнения для программных приложений.

Конструктор

Поставщик контейнеров (EJB Container Provider) - эксперт в области распределенных систем, системной безопасности и поддержки транзакций. Он обеспечивает системный уровень контейнеров, то есть системную оболочку для одного или более компонентов - Enterprise Bean.

Снабженец

Поставщик бизнес-компонентов (Enterprise Bean Provider) - аналитик в функциональной области, который реализует бизнес-компоненты как разработчик или подбирает готовые.

Монтажник

Компоновщик Приложений (Application Assembler) - также эксперт-функционал, собирающий программное приложение из строительных блоков - бизнес-компонентов. Его взгляд на соответствующий бизнес должен быть более общим и универсальным, чем у Снабженца - Поставщика бизнес-компонентов.

Прораб

Внедренец (Deployer) - специализируется в установке приложений. Он настраивает приложение на реальную среду.

Управдом

Администратор системы (System Administrator) - обеспечивает работоспособность системы на этапе эксплуатации.

Конечно, то, что компания Sun описала именно такие роли, не означает, что любой проект, связанный с Enterprise Java Beans обязательно требует одного и только одного указанного специалиста и именно такой состав комплексной бригады. Да и найти, скажем, готового поставщика контейнеров не так-то просто. Что совершенно необходимо - так это не упустить специфические для компонентного проекта моменты: выбор архитектуры и способы реализации системных служб, определение структуры и поведения контейнеров и проработка вопросов внедрения (развертывания).

Завершив экскурс в EJB, можно привести определение Сервера Приложений «с большой буквы». Сервером Приложений называется программный продукт, поставляющий среду выполнения для прикладных компонентов, расположенный между клиентом - с одной стороны и данными и прикладными программами - с другой, который может обеспечить интеграцию различных источников данных и прикладных ресурсов и предоставить компонентам необходимые для них сервисы.

Разочарованный читатель возмутится: «Зачем же нам объясняли про EJB, если в определении про них нет ни слова!» Попробую пояснить. Я намеренно привела универсальное определение Сервера Приложений, которое относится ко всем типам компонентов (CORBA, EJB, COM+). Серверы Приложений, зародившись внутри технологии EJB, оказались столь удобны, что достаточно уверенно продвигаются как единое решение для всех компонентных технологий. Реализации Серверов Приложений уже умеют работать с разными компонентами. В качестве примера приведу Application Server компании Inprise, который можно успешно использовать в среде компонентов EJB и CORBA. Другой наблюдаемый процесс - смыкание технологий Java и CORBA. С небольшой долей натяжки можно считать, что EJB могут иметь двойное гражданство, а именно представлять собой еще и CORBA-объекты. С моей точки зрения, поддержка CORBA является необходимым условием для конкурентности реализации Сервера Приложений. Ведь из всех перечисленных технологий только эта поддерживает Унаследованные Системы - функционально пригодные, но технически устаревшие. Если считать парк автоматизации современного предприятия или компании некоторым поселением - деревушкой или городком, создаваемая интеллектуальная компьютерная среда должна включать уже существующие постройки. Одинаково неправильно требовать сноса существующих зданий или не обращать на них внимания.

Другой аспект выбора реализации Серверов Приложений заключается в функциональности, которая наиболее приоритетна. Попробуем разделить Серверы приложений на группы.

1. Интеграционный Сервер Приложений. (Application -integration-centric application server)

Основная задача такого Сервера - интеграция Бизнес-приложений в единую интеллектуальную среду. Такие Серверы особенно актуальны для организации приложений, связанных с задачами типа Supply Chain (Цепочки Поставщиков) и электронной коммерции. К таким серверам относятся реализации крупнейших поставщиков брокеров объектных запросов - компаний Inprise и Iona.

2. Информационный Сервер Приложений (Data-centric application server)

Деятельность такого сервера сконцентрирована на манипулировании данными. В качестве хранилищ могут выступать произвольные приложения, которые, в частности, не обязательно представляют собой реляционные базы данных и, уж тем, более объектные. Такие серверы берут на себя организацию представления распределенных данных, хранящихся в различных источниках, в объектной парадигме. Естественно, Oracle поставляет серверы именно такого типа.

3. Обрабатывающий Сервер Приложений (Processing-centric application server)

Центральной заботой таких серверов является обеспечение специфической бизнес-логики. Например, сервер, реализующий распределенные вычисления, или сервер ERP-системы. К таким реализациям относится IBM Websphere.

4. Управляющий Сервер Приложений (Rules-based application server)

Такие серверы являются подмножеством Обрабатывающих Серверов Приложений, но в отличие от них сконцентрированы на выполнении определенных бизнес-правил. Они ориентированы прежде всего на область электронной коммерции. Примером таких серверов является реализация от компании Vision Software.

5. Сервер XML (XML Server)

Этот сервер представляет собой подмножество Информационного сервера, с той лишь разницей, что в качестве хранилищ данных выступают XML - документы. С другой стороны, такой сервер может представлять собой подмножество Интеграционного сервера, в котором в качестве механизма интеграции выбран XML. Известна реализация такого сервера от компании Bluestone Software.

Не следует думать, что разделение Серверов Приложений по группам такое четкое. Наиболее интересные экземпляры Серверов Приложений гармонично сочетают в себе достоинства различных групп. Кроме того компании-разработчики активно развивают свои продукты. А каждая новая версия, естественно, богаче предыдущей.

Предвижу следующий вопрос читателей: - « А это уже где-нибудь работает?» Ответ - «Да!». Особенно востребованы Сервера Приложений во всем, что касается использования Internet. И за счет поддержки распределенности, возможностей выравнивания загрузки, отслеживания распределенных неоднородных транзакций, управления безопасностью и многих других своих возможностей. Именно эти интеллектуальные приложения находят в Серверах Приложений могучую опору.

Рис. 5. Java 2 Enterprise Edition

Вскользь упомяну о следующих усилиях по созданию технологии компонентного программного обеспечения, снова связанных с Java. Это J2EE (Java 2 Enterprise Edition) - стандарт для многозвенных систем уровня предприятия, прикладная платформа, обеспечивающая взаимодействие Enterprise Java Beans, Java Server Pages, апплетов и сервлетов. рис. 5 в точности иллюстрирует то, как это выглядит у компании Sun.

Средства взаимодействия компонентов располагаются в нижней части рисунка. J2EE впервые стандартизовала выполнение родного для Java протокола удаленных вызовов методов через Internet - IIOP (Internet InterOrb Protocol). Таким образом, к сотрудничеству между CORBA и Java добавился еще один пункт. Серверные компоненты заключены в контейнеры, взаимодействующие с помощью специальных коннекторов. На уровне контейнеров задаются системные сервисы: Транзакций, Сообщений и Почты. На верхнем уровне находится API-интерфейс и Средства управления. Сказать об этой технологии в контексте Серверов Приложений меня вынудило не только то, что этот стандарт является логическим развитием технологии EJB, в которой впервые определился наш герой, но и то, что уже появляются Серверы Приложений, удовлетворяющие новому стандарту. Я имею в виду уже упоминавшийся Application Server (Inprise).

Но, стоп, боюсь, что Вы уже устали от обилия технологий и нагромождения стандартов? Если да - то тогда обратитесь к рис. 6, где я попыталась свести все воедино.

В защиту всего этого хозяйства хочу отметить, что, говорят, наши предки -обезьяны прекрасно жили на деревьях и, если и сплетали себе нечто вроде гнезд, но ни один из нас не согласился бы там жить постоянно, разве что для того, чтобы испытать захватывающее приключение. Так и программные приложения постепенно слезли с деревьев и начали строить себе дома. А если говорить о стандартах в строительстве, то их все равно намного больше, чем на сегодняшний день существует в информационных технологиях. В утешение хочу добавить, что наши стандарты неплохо уживаются друг с другом. По крайней мере, учатся это делать. Как пример, хочу обратить ваше внимание на неоднократное упоминание лакомого современного стандарта XML в этой статье, которая вроде бы написана совсем о других стандартах.

Легче ли создавать программные системы с помощью Сервера Приложений? Я бы покривила душой, если бы однозначно ответила - «да», хотя мне и очень хочется это сделать. Как всяким инструментом, к тому же непростым, им надо научиться пользоваться. Его нужно применять только в определенных условиях, как по инфраструктуре, так и по программному обеспечению. Отдельный вопрос - какую именно реализацию Сервера Приложений следует использовать. Сервер Приложений - верный друг, но только для заботливого и грамотного хозяина.

Об авторе

Марина Аншина - сотрудник отдела системной интеграции компании «ТопС, Системный Интегратор». С ней можно связаться по электронной почте по адресу: [email protected]

Моральный кодекс молодого строителя программного обеспечения - Сервера Приложений

Источники

Были рассмотрены возможности двух серверных платформ для терминальных решений. Но на рынке произошли изменения: появился новый сервер от Microsoft — "MS Windows 2000 Advanced Server", практически полностью уничтожающий различия между продуктами Microsoft и Citrix. Новый сервер обладает такими возможностями, как:

• Служба кластеризации и перераспределения нагрузки
• Поддержка протокола RDP5
• Поддержка доступа к серверу при помощи браузера IE (компонент ACTIVE X)
• Доступ к серверу печати, COM-портам и буферу обмена клиента.

Также стоит отметить появление на рынке продукта от компании Corel, который, к сожалению, в продажу на территории России не поступал и пока никакого независимого тестирования не проходил.

Основные задачи, которые выполняет сервер приложений — выполнение задач клиента и отправка изменившегося окна клиента. Здесь имеет смысл отметить два момента.

Во-первых, с какой скоростью сервер будет выполнять задачи — если скорость соединения высока, то именно от скорости выполнения задач будет зависеть общая производительность системы.

Второй показатель — скорость доставки обновленного экрана клиента. Здесь тоже имеет смысл обратить внимание на то, что даже если сервер у Вас фантастически быстр, то на повышение производительности будет влиять скорость соединения сервера с клиентом.

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

Также следует обратить внимание на тот уровень комфорта при работе с терминалом, который готовы воспринять пользователи. Так, к примеру, машинистке набивающей платежки в банке не надо мгновенно видеть результаты своей работы на экране — пауза в 0.1 секунду ее может вполне устроить. Также пользователя может вполне устроить 16 цветов при запуске приложения вместо 256. Проще говоря, перед тем как построить любую терминальную систему, вам требуется ознакомиться с техническими возможностями предприятия, запросами пользователей и теми бизнес-задачами, которые будут выполняться на сервере.

Выбор сервера приложений

Основной задачей при выборе сервера приложений является оптимизация мощности процессора и объема оперативной памяти. Основная проблема состоит в том, чтобы подсчитать нужные ресурсы для большой группы пользователей, имея мало представления о них и о том, как они могут загрузить сервер. То есть вы наверняка можете предположить, что одна секретарша использует немного ресурсов, но что произойдет, когда таких пользователей будет подключено к серверу более 50?

Во-первых, данные пользователи постоянно не используют предоставленные им вычислительные ресурсы, во-вторых, даже в их работе существуют серьезные всплески активности — к примеру, загрузка Word. Также надо предполагать, что существуют другие пользователи, возможно имеющие другие параметры по загрузке сервера — к примеру, программисты.

На данном этапе вам, возможно впервые, придется провести анализ "поведения" пользователей, которых вы собираетесь подключить к терминальному серверу.

Пример

Общее количество рабочих мест — 20. 10 пользователей используют только Microsoft Word, Excel, Outlook, IE (отдел продаж, маркетинга и PR), 3 пользователя используют только 1C (бухгалтерия), 4 пользователя используют IE, Outlook (начальники отделов), 2 пользователя очень редко используют Word и, наконец, остается системный администратор, загружающий все подряд от PhotoShop до J++.

Предположим, что внутри пользовательских групп нагрузка распределяется равномерно (обед у всех в одно и тоже время), также предположим, что те программные средства, которые используют пользователи, в целом равномерно загружают сервер (проще говоря, печатанье в Ворде не порождает всплеска использование процессора).

Итак, вы каким-либо способом рассматриваете то, как пользователь использует компьютер в рабочий день. То есть смотрите за тем, какие действия он за ним производит. Данный контроль можно осуществлять двумя способами, во-первых, запустить какого-нибудь робота, что бы он записывал нажатия на клавиши и щелчки мышью, во-вторых, вы можете подключить пользователя к какому-либо свободному терминальному серверу и посмотреть какую нагрузку он будет производить в течение дня. Далее результаты работы робота можно воспроизвести уже на терминальном сервере и найти уровень загруженности системы.

Какие параметры вы должны получить:

1. Пиковая нагрузка на процессор. Частота пиковой нагрузки на процессор за день. Средняя продолжительность такой нагрузки.
2. Средняя загрузка процессора за день. Желательно также найти почасовую среднюю нагрузку.
3. Пиковое использование памяти. Частота пиковой нагрузки за день. Средняя продолжительность такой нагрузки.
4. Среднее использование памяти в течение дня, почасовая средняя нагрузка.

Вы должны провести такое испытание со всеми группами пользователей.

Далее вы легко можете получить так называемые "минимальные" показатели сервера приложений — помножьте средние показатели на количество пользователей в группе и сложите все группы. вы получите просто фантастические запросы к памяти — для нашего примера: около 780 Мбайт оперативной памяти и около 2 ГГц суммарной занятости процессора.

Но не стоит пугаться — метод, описанный выше неправилен:), так как терминальный сервер умеет эффективно использовать память.

К примеру, общий объем загружаемых компонентов Microsoft Word в памяти около 9 Мбайт, но 8 Мбайт из данного блока приходится на словари, графику и помощника. Когда будет запущена следующая копия Word, эти 8 Мбайт не будут загружены или продублированы — они будут доступны обеим копиям. Если какая-нибудь из них попробует изменить эту восьми мегабайтную часть, то измененная часть будет отделена и потребует немного памяти. Использование данного механизма распределения памяти позволяет экономить память. Но степень данной экономии вы сможете определить, только используя второго, подключенного к терминальному серверу клиенту. То есть вы подключаете второго клиента или запускаете записанную ранее роботом программу действий второй раз.

Итак, вы смогли определить примерные размеры приложений при повторном запуске. Далее вы должны составить примерную временную таблицу загруженности данного приложения в память. К примеру: Word — 27% времени, Excel — 10% времени, IE — 100% времени. Далее вы умножаете то количество памяти, которое действительно требуется на количество пользователей использующих данное приложение и на полученную таблицу. Получившиеся "мегабайто-сапиенс" и есть то минимальное количество памяти, которое вам потребуется (для нашего примера — около 340 Мбайт).

Процессорная мощность может быть вычислена и нормальным способом — вы можете просто сложить среднюю загруженность терминального сервера. Далее перевести эту загруженность в какие-либо масштабируемые единицы — к примеру, мегагерцы или показатели производительности какого либо теста процессора. Здесь стоит обратить внимание на то, что мегагерц — наихудший вариант, ибо 166MMX работает не 5 раз медленнее 800 МГц Athlon, но какой показатель наилучшим образом подходит для сравнения, к сожалению, сказать сложно.

Таким образом, вы сможете получить показатель на уровне 500-600 МГц для нашего примера. Если же вы подсчитаете, насколько каждое отдельное приложение загружает сервер, и умножите данный результат на цифры из полученной ранее таблицы, то, возможно, получите меньший и более правдивый вариант.

Далее нужно выяснить, как перегрузки влияют на сервер. Предположим, что существуют два вида перегрузок — утренние и обыкновенные. Под утренними понимается обыкновенная загрузка бездисковых станций, под обыкновенными — загрузка новых приложений.

вам должно быть известно количество таких моментов в течение рабочего дня и их распределение. Если таких перегрузок немного, то вы смело можете забыть про них, если же очень много то вам придется выделить дополнительные ресурсы памяти и процессора. К примеру, выяснилось, что обычная перегрузка происходит каждые 20 минут. При этом загрузка процессора возрастает на 200 МГц, плюс затрачивается в среднем около 10 Мбайт памяти. Продолжительность около 15 секунд. Практически именно данные показатели вы должны прибавить к минимальным. А вот утренняя перегрузка обладает другими качествами — предположим 20 перегрузок в течение 10 минут, длительностью около 20 секунд. вам тогда придется учитывать более сложную ситуацию — возникновение, скажем, двух перегрузок одновременно.

Итак, в итоге вы получили показатели: процессорная мощность — около 600 мегагерц процессор, 400 мегабайт оперативной памяти. Далее вы должны выделить память для самой операционной системы и ее сервисов. К примеру, если вы собираетесь инсталлировать Windows 2000 Advanced Server, смело прибавляйте 128 Мбайт памяти и около 40 МГц для внутренних задач.

Итог — 640 МГц на 512 Мбайт оперативной памяти.

Данный алгоритм позволяет найти нужную именно вашей организации мощность сервера. Я специально не стал приводить результаты тестов, которые проводил самостоятельно, или опубликованные результаты от западных компаний, дабы вы самим могли оценить эффективность терминальных решений.

Если вашим пользователям потребуется часто пользоваться жестким диском, рассмотрите возможность использования SCSI-контролера и SCSI-диска — это позволит разгрузить процессор, и уменьшить количество перегрузок.

В любом случае, даже если у вашей организации много ресурсов для выполнения таких задач, не стоит скупать Xeon"ы и устанавливать гигабайты памяти — добавить второй процессор чаще оказывается намного проще, чем потратить безрезультатно пару тысяч долларов.

После выбора

Итак, вы купили нужный сервер, протестировали его и теперь перед вами стоят задачи конфигурирования и инсталляции программного обеспечения.

Во-первых, вы должны выбрать, будете ли вы использовать продукты компании Citrix или остановитесь на продуктах от Microsoft. Более дорогой вариант — Metaframe, обладает несколькими не очень важными с моей точки зрения возможностями:

• Program Neighborhood. Применение данного компонента практически бессмысленно, если количество пользователей менее 100, в любом случае вы сможете, используя стандартные средства администрирования, добиться той же эффективности
• Video Frame — данный компонент позволяет нескольким операторам или скажем только вам наблюдать за работой клиентов и если надо вмешиваться в их работу.
• Поддержка передачи звука
• Поддержка IPX/SPX, и некоторых другие протоколы, включая соединение по нуль модемному кабелю.

Наиболее важное отличие между данными терминальными серверами лежит в протоколе подключения клиентов. Microsoft использует для этого RDP 5.0, Citrix — ICA.

Эти протоколы имеют собственные плюсы и минусы. К примеру, ICA — платформенно-независимый протокол, клиент может работать на любой платформе, будь он веб-браузером или старым добрым Lunix. Протокол от Microsoft работает только на 2 клиентах — WIN16 и WIN32, но это дает ему возможность использовать вызовы WINAPI, что резко сокращает размер и количество передаваемых пакетов. В итоге данный протокол чаше демонстрирует возможность комфортной работы на полосе 4-8 Кбайт в секунду, когда Citrix даже при установке SPEEDSCREEN2 (утилиты для сжатия потока ICA) не демонстрирует показатели лучше 10 килобайт в секунду.

Как это может отразиться на работе вашего предприятия? Если вам придется подключать удаленное подразделение, то использование коммерческих линий часто оказывается очень дорогим удовольствием и сжатие потока будет очень важно. К примеру, для очень комфортного подключения одного клиента по RDP5.0 придется использовать два модема 33.6, а по ICA — в обязательном порядке выделенный канал.

Второй фактор при покупке данных продуктов — возможность приобрести их на территории России. Если продукты Microsoft еще присутствуют, то продукты от компании Citrix вам придется поискать. Как дополнительный плюс надо отметить русифицированость продуктов Microsoft.

Инсталляция

Windows 2000 Advanced Server

Инсталляция обычно проходит без особых проблем, единственное, что от Вас потребуется — это установить терминальные службы в качестве компонента. Далее никаких особенных настроек от Вас не понадобится, вам потребуется лишь лицензировать сервер на более чем 2 подключенных клиента и на этом настройка закончится.

Citrix Metaframe 1.8

Установка также не должна вызвать у Вас каких-либо проблем, никаких сложных настроек при установке указывать не надо.

Но если у Вас возникли какие-либо проблемы с установкой какого-либо из этих продуктов, то вы легко сможете найти инструкции по установке на нескольких российских серверах.

Настройка сервера после установки

Здесь я приведу несколько советов по улучшению состояния серверов:

1. Отключите сжатие потока, если ваши клиенты не обладают мощными процессорами. Это также должно снизить нагрузку на сервер.
2. Не используйте сервер как прокси, веб-сервер, сервер баз данных. Для этих целей выделите другую рабочую станцию.
3. Отключите или снизьте до 1-2 Мбайт кэширование битмэпов в случае использования бездисковых клиентов. Это разгрузит сеть и убыстрит работу.
4. Уменьшите до 640х480 точек и 16 цветов размер клиентского десктопа. Это резко снизит нагрузку на сеть и даст еще немного ресурсов серверу.
5. Отключите любые скрин-сейверы на стороне клиента, или, проще говоря, не инсталлируйте их.
6. Попытайтесь избавиться от любых DOS-компонентов или любых компонентов, активно использующих графику.
7. Отключите всевозможные видеоэффекты, заставки, фоны рабочего стола и тому подобные прелести.
8. Отключите шифрование, так как оно примерно на 5 процентов снижает скорость работы клиента.
9. Попробуйте отделить сегмент сети, в которой работает ваш сервер приложений и клиенты, это снизит нагрузку на сеть.
10. Увеличьте кэш битмапов до максимума, в случае использования дисковых клиентов. Это резко увеличит скорость обновления экрана.
11. Запретите пользователям использовать какие либо другие средства, кроме регламентированных (обязательно выключите пинбол при установке сервера, так как данное приложение готово загрузить все предлагаемые ему мощности;))

Данные советы, надеюсь, помогут высвободить определенные ресурсы, как сети, так и сервера приложений. Но существуют ситуации, когда требуется добиться еще большего результата в использовании сети — к примеру, получить возможность работы на 2-3 килобайтной полосе.

Такие ситуации, к сожалению, не редкость, если организация обладает разветвленной сетью географически удаленных терминалов и не обладает ресурсами, чтобы использовать дорогие каналы. С момента выхода первой статьи мне пришло 3 письма с вопросами о построении именно таких сетей.

Основной вопрос в таких сетях: как отразится резкое снижение полосы пропускания на качестве работы.

Я использовал специальное программное обеспечение, чтобы уменьшить возможности моей сетевой карты и оценить, как резкое сокращение возможностей канала сказывается на работе.

Задержка при передаче данных была принудительно установлена в 0.25 секунды (я думаю, что большие задержки даже в России получить сложно). Все битмапы были предварительно кэшированы. Использовался RDP 5.0.

Канал 8 Кбайт в секунду

Пауза чувствуется при открытии любого окна, складывается ощущение, что при нажатии на кнопку только через секунду на экране показывается диалоговое окно. При печати текста возникает ощущение наличия в клавиатуре огромного буфера — символов этак на 30. Очень долго происходит соединение с сервером: экран авторизации появляется только через 15 секунд.

Канал 6 Кбайт в секунду

Резко возрастает время появления диалогов, даже при повторном запросе. Пауза между выводом символа в Word и нажатием кнопки около секунды. Но нормальная работа еще возможна.

Канал 4 Кбайта в секунду

Я ожидал открытие экрана авторизации около минуты. Технически работать еще можно, но ни скроллинг, ни любой вывод графики уже невозможен. При попытке нажатия на кнопку "Пуск" приходится ждать около 2 секунд. Данный режим подходит только для специализированных приложений.

Канал 2 Кбайта в секунду

Технически данная информация может помочь вам в принятии решения о подключении удаленного терминала. Если терминал используется для работы операционистки, то миграция с DOS на такую систему не прибавит комфорта (привычного для Windows), но и не понизит качества работы.

Если вы собираетесь устанавливать сервер именно для такого рода клиентов, то вам стоит задуматься о снижении расходов на него. Так как клиент все равно не сможет мгновенно получать информацию, то и не требуется мгновенное исполнение задач.

Если вам требуется консультация по установке терминальных серверов или построении корпоративных систем управления на их основе, то пишите мне по почте.

Что? Какое еще серверное программирование? Что это за беда? И зачем она нам нужна?

Мы, вроде бы, научились создавать Web-страницы в среде Dreamweaver. Мы даже научились создавать с его помощью целые Web-сайты и публиковать их на Web-сервере. Мы изучили две разновидности дизайна страниц: фреймовый, когда сайты строятся на основе наборов фреймов, и табличный, когда содержимое страницы помещается в большую сложную таблицу. Мы познакомились с таблицами стилей, метатегами и серверными директивами. И, наконец, узнали о Web-программировании и Web-сценариях, позволяющих добавить "жизни" нашим статичным страничкам. Что же еще надо для счастья?

Да, изученного ранее нам вполне хватит, чтобы создавать вполне приличные сайты. Многие Web-дизайнеры на этом и останавливаются. Но ведь мы хотим большего, не так ли?

Так давайте же сделаем следующий шаг - перейдем от страниц, хранящихся в файлах на сервере, к страницам, генерируемым специальными программами. Как раз написанием таких программ и занимается серверное программирование.

Но давайте по порядку. И начнем мы с того, что выясним, зачем нужны эти серверные программы.

Что такое серверное программирование

Действительно, что это такое и с чем его едят?

Зачем нужны серверные программы

Вы когда-нибудь посещали интернет-магазин? Например, популярнейший "Озон" (http://www.ozon.ru) . Помните, как там выполняется заказ товара?

Если не помните или вообще не знаете, что такое интернет-магазин, давайте вспомним (или узнаем).

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

Что происходит при этом? Как обрабатываются введенные вами данные? Неужели самим Web-обозревателем?

Отнюдь. Эти данные обрабатываются на Web-сервере.

Интернет-магазин - просто один из примеров, пришедших в голову автору, являющемуся поклонником и постоянным клиентом вышеупомянутого "Озона". Точно так же работают серверы электронной почты, основанной на Web, поисковые машины, электронные доски объявлений, форумы, вообще, любые Web-сайты, принимающие от посетителя какие-то данные и обрабатывающие их. Во всех этих случаях Web-обозреватель принимает от посетителя данные и отправляет их Web-серверу, который обрабатывает их и выдает результат обработки в виде автоматически сформированной Web-страницы.

Как это происходит на деле? Сейчас мы это выясним. И первым делом ответим на вопрос...

Как Web-сервер обрабатывает данные пользователя

Итак, каким же образом программа Web-сервера обрабатывает данные, отправленные ей пользователем?

Да никак. Web-сервер не приспособлен их обрабатывать. Его задача: прием от Web-обозревателя запроса на файлы (Web-страницы, таблицы стилей, графические изображения, фильмы, звуки, архивы, исполняемые файлы и т. п.), поиск этих самых файлов на жестких дисках серверного компьютера и отправка найденных файлов назад Web-обозревателю. Это его основная задача. Конечно, некоторые особо мощные серверы могут выполнять дополнительные действия над отправляемыми файлами перед собственно их отправкой (в частности, выполнять серверные директивы). Есть и программы-"многостаночники", выполняющие функции не только Web-сервера, но и сервера FTP, почты, новостей UseNet и бог знает чего еще. Но основная функция: простая выдача файлов по требованиям клиентов -и не более того.

Секрет в том, что данные посетителя обрабатываются не самим Web-сервером. Для этого применяются специальные программы, работающие вместе с Web-сервером на том же серверном компьютере. Они называются серверными программами, не имеют интерфейса пользователя и "общаются" только с Web-сервером, принимают от него введенные пользователем данные и возвращают ему результат. Этим они коренным образом отличаются от клиентских программ, работающих непосредственно с пользователем. (К клиентским программам относится, в частности, ваш любимый Web-обозреватель.)

Из этого следует, что Web-сервер умеет-таки принять данные от пользователя. Да, это входит в его основную задачу: принять данные и перенаправить их серверной программе. В свою очередь серверная программа их обработает и вернет Web-серверу результат.

Вот тут-то и начинается самое интересное. Дело в том, что результат, возвращаемый серверной программой Web-серверу, - это не что иное, как обычный HTML-код! Фактически серверная программа возвращает готовую Web-страницу, сформированную на основе данных, введенных посетителем. Такая страница называется динамической, в отличие от статических страниц, написанных Web-дизайнером и сохраненных в файлах на дисках серверного компьютера. А уж эту динамическую страницу Web-сервер и направляет клиенту в качестве ответа на введенные данные.

Серверные программы делятся на следующие четыре вида.

1. Исполняемые программы, работающие через интерфейс CGI (Common Gateway Interface - общий интерфейс обмена), так называемые CGI-npoграммы. Эта разновидность серверных программ - самая старая, однако отнюдь не устаревшая.
   
2. Расширения Web-сервера (приложения формата ISAPI, NSAPI, модули расширения Apache и т. п.). Новый способ, позволяющий встраивать серверные программы в сам Web-сервер, делая их его составными частями. Впервые предложен фирмой Microsoft для их сервера Microsoft Internet Information Server (интерфейс ISAPI) и разработчиками популярного бесплатного Web-сервера Apache.
   
3. Активные серверные страницы (ASP, JSP и др.). Фактически это обычные статические Web-страницы, сохраненные в файлах, Которые, кроме обычного HTML-кода, включают в себя команды, обрабатываемые либо самим Web-сервером, либо его расширением. Также новый способ, впервые предложенный Microsoft для того же Internet Information Server.
   
4. Серверные сценарии, написанные на интерпретируемом языке (Perl, Python, VBScript, JavaScript и др.). Обычные сценарии, работающие через интерфейс CGI или ISAPI на стороне сервера.
   

Теперь рассмотрим все это разнообразие подробнее.

CGI-программы представляют собой обычные исполняемые файлы, написанные на любом языке программирования и откомпилированные в ма шинный код процессора. Они не имеют интерфейса пользователя (как и все серверные программы), а работают с Web-сервером, получают от него входные данные и ему же пересылают результаты своей работы. Запускаются они самим Web-сервером, когда в них возникает нужда (когда необходимо обработать полученные от пользователя данные), и работают под управлением операционной системы серверного компьютера. При этом, если Web-серверу поступает одновременно несколько запросов на обработку данных от пользователей, он запускает соответствующее количество копий CGI-программы.

К достоинствам CGI-программ можно отнести легкость создания (многие среды разработки программ поддерживают создание таких приложений, в частности популярнейший Borland Delphi, начиная с версии 3) и простоту отладки. Также, поскольку CGI-приложения представляют собой независимые программы, они выполняются отдельно от Web-сервера (как говорят программисты и системные администраторы, выполняются в другом адресном пространстве). Это значит, что при сбое в CGI-программе завершается только она - сам Web-сервер остается "на плаву". А недостаток у CGI-программ всего один: большой расход системных ресурсов, поскольку для обработки каждого набора данных запускается отдельная копия серверной программы. И если Web-серверу поступит слишком много запросов на обработку данных, серверный компьютер может и зависнуть.

Расширения Web-сервера - более новая разновидность серверных программ. Они представляют собой обычные библиотеки DLL, в которых реализована вся логика серверной программы. Такие библиотеки как бы встраиваются в программу Web-сервера и работают как ее неотъемлемая часть. Поскольку библиотеки DLL работают только в среде Windows, для того чтобы создавать расширения в иных операционных системах, были придуманы и другие форматы. В частности, модули расширения сервера Apache не являются библиотеками DLL,

Именно в виде библиотек DLL создаются расширения Web-серверов Internet Information Server фирмы Microsoft и Netscape Web Server фирмы Netscape. В первом случае расширения имеют формат ISAPI (Internet Server Application Programming Interface - интерфейс программирования приложений интернет-сервера), а во втором - NSAPI (Netscape Server Application Programming Interface - интерфейс программирования приложений сервер^ Netscape). Формат модулей расширения Apache так и называется - модули Apache.

Достоинство у расширений Web-сервера одно: бережный расход системных ресурсов. Дело в том, что для обработки всех наборов данных пользователя запускается всего один экземпляр расширения, который отнимает существенно меньше ресурсов, чем уйма запущенных CGI-программ. Однако расширения труднее создавать и отлаживать, к тому же они не так безопасны.

Как CGI-программы. Поскольку они работают как часть Web-сервера, любая ошибка в расширении приведет к зависанию сервера.

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

Как уже говорилось, активные серверные страницы - это обычные Web-страницы, включающие в себя особые серверные сценарии, выполняемые самим Web-сервером или специальной серверной программой (CGI-приложением или расширением Web-сервера). В частности, ASP (Active Server Pages - активные серверные страницы), поддерживаемые Microsoft Internet Information Server, и JSP (Java Server Pages - серверные страницы, написанные на JavaScript), поддерживаемые рядом других Web-серверов, работают именно таким образом. Серверные страницы ASP пишутся на языках JavaScript и VBScript, a JSP - только на JavaScript.

Достоинства активных серверных страниц вы уже знаете: легкость и быстрота написания и простота отладки. Кроме того, поскольку активные серверные страницы -- это обычные Web-страницы с "вкраплениями" программного кода, их написание легко освоят все, кто знаком с HTML. Недостаток: относительная медлительность и повышенные требования к системным ресурсам.

Серверные сценарии подобны активным серверным страницам тем, что являются интерпретируемыми, однако представляют собой "чистый" программный код, без HTML-""примесей". Интерпретатор практически всегда представляет собой CGI-программу, однако ничто не мешает разработать его в виде расширения Web-сервера. Сценарии обычно пишутся на языке программирования Perl, специально предназначенном для обработки текста; также используются языки Python, JavaScript, VBScript и даже (как говорят) язык командных файлов MS-DOS. Фактически писать сценарии можно на любом языке программирования, для которого есть интерпретатор.

Достоинства и недостатки серверных сценариев те же, что у активных серверных страниц. Однако сценарии потребляют исключительно много системных ресурсов, даже больше, чем CGI-приложения. Ведь для обработки каждого набора данных пользователя запускается своя копия интерпретатора, а интерпретатор, в свою очередь, расходует много ресурсов на обработку сценария. И все же, несмотря на это, сценарии - самый популярный способ создания серверных программ.

В табл. 15.1 приведены расширения файлов серверных программ.

Таблица 15.1. Расширения файлов серверных программ

Вот мы и рассмотрели, как Web-сервер обрабатывает (точнее, не обрабатывает) данные пользователя. Теперь переместимся в начало цепочки и рассмотрим, как Web-обозреватель отправляет данные пользователя серверной программе.

Как Web-обозреватель отправляет введенные данные

В начале этой главы мы говорили о том, что для сбора данных посетителя используются элементы управления, помещаемые на самих Web-страницах. Это обычные элементы управления, знакомые вам по приложениям Windows: поля ввода, кнопки, списки, флажки и пр. Посетитель сайта вводит в них данные и нажимает особую кнопку, запускающую отправку данных Web-серверу, а значит, и серверной программе.

Элементы управления, предназначенные для ввода данных посетителя, помещаются в форму. Форма - это особый элемент страницы, выполняющий собственно кодирование данных и пересылку их Web-серверу. (Можно сказать, что форма является родителем для элементов управления.) Сами же элементы управления только принимают данные от посетителя, но не кодируют и не передают их.

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

Например:

Здесь мы рассмотрели идеальный случай, когда значения каждого элемента управления содержат только допустимые с точки зрения протокола HTTP символы: буквы латинского алфавита, цифры, тире, подчеркивания и некоторые другие знаки. (Как вы помните, HTTP - протокол передачи файлов, используемый Web-сервером.) Если же вы передаете данные, содержащие недопустимые символы, скажем, пробелы или буквы русского алфавита, каждый такой символ будет представлен в виде шестнадцатеричного кода, которому предшествует знак процента, например, так (закодированные символы пробела выделены полужирным шрифтом):

Благодаря такому формату данных написание обрабатывающих их серверных программ становится очень простым. В частности, язык Perl имеет встроенные средства расшифровки для этого формата.

Представленные в вышеуказанном виде данные впоследствии кодируются с использованием одного из предопределенных методов кодирования и отправляются по Сети серверной программе. Всем этим фактически занимается форма (но не элементы управления).

Сам процесс отправки данных начинается после того, как пользователь нажмет особую кнопку. Эта кнопка носит название Отправить (Submit -в англоязычных программах) и обязательно должна присутствовать в форме. Также в форме может присутствовать кнопка Сброс (Reset), обнуляющая введенные пользователем данные. Как правило, эти кнопки располагаются в самом низу формы.

Вы можете считать, что форма - это некое подобие обычного диалогового окна Windows-приложения, принимающего данные от пользователя, кодирующего их определенным образом и отсылающего основному окну. (Диалоговые окна Windows-приложений также обязательно имеют две кнопки: ОК и Отмена (Cancel).) Но если в случае обычного Windows-приложения программист должен явно задать, как будут шифроваться и пересылаться данные, в случае с Web-формой этого делать не нужно. Вам необходимо будет только задать три обязательных параметра:

• интернет-адрес серверной программы, которая будет обрабатывать данные формы;
  
• метод кодирования отправляемых данных;
• один из двух методов отправки данных.
  

О методах отправки данных мы поговорим чуть позже. А сейчас выясним все о двух других обязательных параметрах формы.

Интернет-адрес серверной программы очень похож на интернет-адрес любого другого файла, например Web-страницы. Взгляните сами - так будет выглядеть адрес CGI-программы:

http: //www. somesite. ru/bin/program.exe Так - адрес расширения Web-сервера: http: //www.somesite.ru/bin/extension.dll Это - адрес активной серверной страницы:

http: //www. somesite . ru/asps/active_page . asp

А это - адрес программы-сценария, написанной на языке Perl:

http: //www. somesite. ru/scripts/perl_script.pl

Как видите, ничего сложного в этом нет. Серверная программа - обычный файл, помещенный на жестких дисках серверного компьютера, и ссылка на него также не представляет ничего особенного.

Для кодирования передаваемых по Сети данных обычно используются три наиболее популярных метода: application/x-www-form-urlencoded, multipart/form-data и (значительно реже) text/plain. Возможно применение и других способов кодирования, но в абсолютном большинстве случаев используются три перечисленных. Вдобавок эти три метода кодирования поддерживаются большинством программ Web-обозревателей.

Примечание

Если вы еще помните, что такое тип данных MIME, то, взглянув на приведенные выше названия методов кодирования данных, сразу увидите, что это как раз типы MIME. Именно с их помощью задаются методы кодирования.

В подавляющем большинстве случаев используется метод кодирования application/x-www-form-uriencoded. Кстати, именно он применяется по умолчанию, если метод кодирования не задан. Метод кодирования multipart/form-data используется, если вы собираетесь отправить на Web-сервер файлы; он обеспечивает соответствующее такому случаю преобразование двоичных данных. Последний метод - text/plain -- представляет данные в виде обычного текста, что может быть полезно, если данные формы будут отправляться по электронной почте (иногда применяется и такой способ передачи данных).

Итак, с кодированием данных разобрались. Остается выяснить, как же эти данные передаются по каналам Сети.

Как данные передаются по Сети

Как вы уже знаете, для пересылки данных по Интернету, да и по любой локальной или глобальной компьютерной сети, используется особый набор.правил, называемый протоколом. Протокол определяет, каким образом данные будут шифроваться и упаковываться для последующей передачи по сети. Естественно, что и передающая, и принимающая программы должны поддерживать один и тот же протокол, чтобы "понять" друг друга. (Иначе возникнет так называемая несовместимость по протоколу передачи данных, штука весьма неприятная.) Собственно, уже говорилось об интернет-протоколах и повторяться сейчас нет смысла.

Также вы знаете, что для пересылки по Сети Web-страниц и связанных с ними файлов (графических изображений, звуков, архивов и т. п.) используется протокол HTTP. Он же применяется и для передачи данных, причем для этого предусмотрены два метода передачи данных. Оба способа широко используются в интернет-программировании и имеют свои преимущества и недостатки. Давайте их рассмотрим.

Первый способ носит название GET по значению соответствующего параметра формы. При его использовании данные передаются как часть интернет-адреса в HTTP-запросе.

Как вы помните, Web-обозреватель для того, чтобы получить от Web-сервера нужный ему файл, отправляет этому серверу так называемый HTTP-запрос, включающий в себя интернет-адрес необходимого файла. Так вот, данные могут быть переданы как часть этого адреса.

Возьмем, например, такой набор данных, приведенный чуть выше:

name1 = Ivan surname = Ivanovich name2 = Ivanov age = 30

Теперь подготовим его для пересылки по методу GET (сами данные выделены полужирным шрифтом):

http://www.somesite.ru/bin/program.exe?name1=Ivan&surname2=Ivanovich&name2=Ivanov&age=30

Как видите, пересылаемые по методу GET данные помещаются в самый конец интернет-адреса и отделяются от него вопросительным знаком. При этом пары "имя" = "значение" отделяются друг от друга знаком "коммерческое и" ("&"). Все очень просто и наглядно.

Такая простота и наглядность представления данных - основное преимущество метода GET. Как говорится, все на виду. Также значительно упрощается отладка Web-страниц: поскольку передаваемый Web-серверу адрес отображается в строке адреса Web-обозревателя, вы всегда сможете увидеть, что именно было передано. (Однако, как вы понимаете, конфиденциальные данные таким методом не передашь - их увидят все, кто стоит за вашей спиной.)

http://www.mysite.ru/bin/choose.exe?chapter=3

Как видите, фактически это ссылки на серверную программу, содержащие один параметр chapter и его значение. Это значит, что все остальные страницы такого сайта формируются серверной программой динамически, на основании полученных параметров. По такому принципу очень часто строятся сайты-справочники, сайты-каталоги программ, электронные магазины и другие сайты, содержащие большое количество классифицированной информации.

К несчастью, метод GET обладает огромным недостатком: с его помощью невозможно передавать большие объемы данных. Это происходит из-за ограничения, накладываемого стандартами на длину интернет-адреса: не более 256 символов. Вычтите отсюда длину собственно адреса серверной программы - и вы получите максимально допустимый размер ваших данных. Второй недостаток метода GET - обратная сторона его достоинства. Данные, пересылаемые им, открыты для всеобщего обозрения и могут быть легко прочитаны в строке адреса Web-обозревателя.

Метод GET стоит использовать, если пересылаемые серверной программе данные заведомо невелики и не являются секретными. В частности, он используется для пересылки ключевых слов поисковым машинам, в сайтах, построенных на основе серверной программы (см. выше) и т. п. Если же вам нужно пересылать объемистые либо конфиденциальные данные, используйте второй метод передачи, называемый POST.

Метод POST передает данные серверной программе все в том же HTTP-запросе, но уже не частью интернет-адреса, а в виде так называемых дополнительных данных. Поскольку размер дополнительных данных не ограничен (по крайней мере, он может быть очень велик), вы можете передавать все, что угодно, в каких угодно количествах. В частности, именно этим способом Web-серверу могут передаваться даже файлы.

Достоинства метода POST: отсутствие ограничения на объем передаваемых данных и "невидимость" их. Недостатки: сложность расшифровки данных и трудность отладки. Методом POST передаются, например, анкетные данные, адреса покупателей в электронных магазинах, литературные произве дения на сайты http://www.stihi.ru и http://www.proza.ru и т. п. В общем, то, что имеет большие объемы.

Как говорят, комитет WWWC намерен вообще со временем отказаться от метода GET и все данные передавать с помощью метода POST. Пока что метод GET просто объявлен не рекомендованным для использования во вновь создаваемых сайтах, реально же он еще поддерживается Web-обозревателями.

Вот мы и выяснили все о серверных программах. Ну, может, не все, но пока нам этого достаточно. Теперь поговорим о том, насколько полно все это поддерживается Dreamweaver MX.

Серверное программирование - подход Dreamweaver

Трудно ли писать серверные программы? Да, трудно. Вероятно, даже труднее, чем Web-страницы.

Однако вспомните, часто ли нам приходилось писать HTML-код вручную? Совсем редко, не правда ли? А все потому, что Dreamweaver заботливо оберегал нас от этого, предоставляя удобный интерфейс для визуального создания страниц. Мы просто писали текст, форматировали его, помещали на страницу изображения, таблицы, применяли к элементам страницы поведения и т. п. Одним словом, чувствовали себя комфортно.

И неужели нам теперь придется писать серверные программы вручную?! Нет, совсем не обязательно.

Уже упоминалось, что Dreamweaver предоставляет неопытным пользователям и вообще тем, кто не хочет иметь дела с JavaScript-кодом, так называемые поведения. Поведение - это уже готовый сценарий, написанный профессиональными программистами и помещаемый в код Web-страницы самим Dreamweaver после того, как пользователь выберет это поведение в меню поведений панели Behaviors. Пользователю не надо заботиться о том, что в определенное место кода страницы необходимо поместить сценарий, выполняющий то или иное действие, ему не нужно будет проверять этот сценарий на наличие ошибок и согласовывать его с другими сценариями. Все это за него делает Dreamweaver.

В самом деле, набор операций, применяемых в серверном программировании, очень невелик. Открыть базу данных, получить из нее какие-то данные, вывести их на странице, записать новые данные - что еще нужно!

Конечно, если вы хотите реализовать какие-то хитроумные действия, вам придется писать серверные страницы "врукопашную". Но, согласитесь, такое бывает нечасто.

Итак, мы выяснили две вещи. Во-первых, Dreamweaver MX поддерживает создание серверных Web-страниц. Во-вторых, для помещения в них сценариев используются хорошо знакомые вам поведения. Dreamweaver предлагает большой набор поведений для серверных сценариев, которых вам хватит на первых порах.

Осталось выяснить, какие именно серверные страницы позволяет создавать Dreamweaver. Точнее, какие технологии создания серверных страниц он позволяет использовать. Таких технологий четыре, и сейчас они будут перечислены.

1. ASP. Эта технология вам уже знакома.
   
2. ASP.NET. Дальнейшее развитие ASP.
   
3. PHP. Бесплатная технология, распространяемая с открытыми исходными текстами. Довольно популярна и часто используется с бесплатными же Web-серверами, например Apache.
   
4. Macromedia ColdFusion. Собственная разработка фирмы Macromedia.
   

Какую же из них выбрать? Ведь нам надо будет создавать примеры Web-страниц.

Давайте выберем ASP. И вот почему.

Для того чтобы работать с серверными страницами, нам понадобится Web-сервер. Без него серверные страницы просто не будут работать. А, возможно, вы знаете, что со всеми более-менее новыми версиями Windows поставляется небольшой Web-сервер. В системах Windows 95/98/ME это Personal Web Server, а в Windows NT/2000/XP - Internet Information Server. Его возможностей нам вполне хватит для экспериментов с серверным программированием.

Так вот, этот Web-сервер полноценно поддерживает технологию ASP. Вы можете писать активные серверные страницы и выполнять их под ним. И вам не придется загружать никаких дополнительных компонентов - все, что вам нужно, уже включено в состав дистрибутивного комплекта Windows. Вот поэтому и был выбран ASP.

Технологию ASP.NET пока что не поддерживает практически ни один Web-сервер; фирма Microsoft пока что не выпустила ни один продукт с поддержкой этой технологии. Для работы с PHP-страницами вам придется искать и загружать по Сети довольно большой дистрибутивный комплект, содержащий обработчик РНР, а потом долго его настраивать. Что касается технологии ColdFusion, то вряд ли вы в состоянии выложить за нее несколько тысяч долларов. Так что вариантов у нас практически нет.

Введение в базы данных

Последнее, что мы рассмотрим в данной главе, - это базы данных и работу с ними. Поскольку львиная доля серверных программ работает именно с базами данных, нам эти знания очень пригодятся. Конечно, мы не будем рассматривать все технологии баз данных во всех подробностях, а, как и раньше, ограничимся кратким ликбезом. Вы сами можете поискать нужные книги и тексты в Сети, если заинтересуетесь этим.

Что такое база данных? Ничего особенного, обычный файл или группа файлов, содержащих данные, организованные особым образом. Если база данных состоит из множества файлов, она все равно остается единым целым. Данные, содержащиеся в базе, обрабатываются при помощи особой программы, называемой процессором баз данных. Процессор баз данных может быть как совершенно отдельной программой, работающей на том же компьютере, что и использующая данные программа, так и входить в ее состав.

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

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

На рис. 15.1 приведен пример такой таблицы. Как видите, эта таблица имеет три поля:

• NAME - название технологии создания серверных страниц, текстовое;
• PRICE - цена программы-обработчика, числовое;
  
• USING - поддерживается ли эта технология в настоящее время, логическое ("да-нет").
  

Кроме того, эта таблица имеет четыре записи, соответствующие технологиям, поддерживаемым Dreamweaver MX: ASP, ASP.NET, PHP и ColdFusion.

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

Как получить доступ к отдельному полю, вы уже знаете, - по его имени. А как получить доступ к нужной записи?

Дело в том, что в один момент времени программа, использующая данные базы, может работать только с одной записью, называемой текущей. Она может извлекать данные из полей этой записи и, возможно, изменять их. Но чтобы получить данные другой записи, программа должна выполнить команду перемещения. При этом процессор баз данных перемещает особый указатель текущей записи на нужную запись, и программа получает возможность работать с ней.

Также программа может использовать поиск нужной записи по какому-либо критерию. Очень часто такой поиск выполняется по значению ключевого поля.

Также программа имеет возможность добавлять новые и удалять ненужные записи таблицы. Чтобы добавить новую запись, программа выполняет команду добавления записи и заносит в ее поля необходимые данные. Чтобы удалить запись, программа сначала должна сделать ее текущей, а потом выполнить команду удаления.

В общем случае, последовательность работы с данными, содержащимися в базе, выглядит так:

1. Программа открывает базу данных, выполняя операцию открытия. Это необходимая операция, без которой невозможно получить доступ к базе.
   
2. Программа открывает нужную таблицу базы. После этого процессор возвращает ей так называемый набор записей (по-английски -- recordset), с которым и работает программа.
   
3. Программа выполняет собственно работу с данными.
   
4. Программа закрывает таблицу, после чего процессор убирает соответствующий этой программе набор записей из памяти.
   
5. Программа закрывает базу данных, разрывая все связи с ней.
   

Учтите, что две последние операции - закрытие таблицы и базы данных -выполнять так же необходимо, как и открытие. Дело в том, что набор записей и прочие структуры данных, формируемые процессором в памяти для программы, работающей с данными, отнимают много системных ресурсов. Поэтому, как только вы закончили работу с таблицей или базой данных, сразу же закройте ее, чтобы освободить ресурсы для других пользователей.

В последнее время большую популярность- приобрели серверы баз данных. Это обычные процессоры данных, но реализованные в виде серверных программ и работающие на серверных компьютерах. Их преимущества перед обычными процессорами данных:

• они работают на серверном компьютере, который, как правило, мощнее клиентского, поэтому их производительность выше;
  
• они обеспечивают большую защищенность данных за счет разграничения доступа и некоторых других механизмов;
  
• они просто мощнее, в смысле, поддерживают больше различных нововведений, появившихся в последнее время.
  

Чтобы получить доступ к серверу баз данных и самим данным, клиентская программа посылает ему особые команды. Для составления таких команд был разработан язык описания запросов SQL (Structured Query Language -язык структурированных запросов). С помощью команд, составленных на этом языке, клиентская программа может открыть нужную таблицу, считать данные, добавить, изменить, удалить запись и, в конечном счете, закрыть базу данных, когда нужда в ней отпадет.

Серверы баз данных применяются сейчас очень часто, а в Web-программировании - почти повсеместно. К наиболее популярным можно отнести Oracle, Microsoft SQL Server, Sybase, мощнейший IBM DB2, Borland InterBase (в России он продается под названием IBase), набирающий популярность PostgressSQL и бесплатный сервер MySQL, распространяющийся с открытыми исходными текстами. Последний сервер, кстати, очень часто используется в связке с Web-сервером Apache и технологией серверных страниц РНР.

На этом рассказ о базах данных и о серверном программировании можно считать законченным.

Уже говорилось, что отправку данных серверной программе выполняют особые элементы Web-страниц - формы. Именно о формах и о работе с ними в Dreamweaver мы с вами будем говорить в следующей главе. А уже потом перейдем собственно к серверному программированию.

Вынесение прикладной логики в отдельный уровень представляет разработчикам дополнительную гибкость в создании распределенных информационных систем. Размещение и выполнение программ на стороне сервера снижает требования к аппаратному обеспечению клиентов и уменьшает проблемы обеспечения совместимости в гетерогенной сетевой среде.

Сервер приложений - это сервисная программа, которая обеспечивает доступ клиентов к прикладным программам, выполняющимся на сервере. Сервер приложений обычно выделяется как среднее звено (рис. 1) в трехуровневой клиент-серверной архитектуре (3-tier):

Модель "сервер приложений"

1. Первый уровень, интерфейсный, как правило, графический (GUI).
2. Средний уровень, исполнимый программный код, размещенный обычно на выделенном сервере.
3. Третий уровень, фоновый - базы данных. Сюда же относятся, унаследованные средства доступа к данным и управления транзакциями.

В сетевой среде сервер приложений является посредником между фронт-энд ами клиентов и серверами баз данных.

Бизнес-логика может быть реализована на стороне сервера как целиком (удаленный код), так и частично (распределенный код). В первом случае к серверу могут обращаться терминалы и «тонкие» клиенты и такое взаимодействие соответствует модели «сервер терминалов». «Толстые» и rich-клиенты могут получать компоненты серверного приложения и выполнять их на своей стороне (например javascript, апплеты, flash).

Мобильный софт

Задачи, решаемые серверами приложений хорошо иллюстрируются на примере мобильных сервисов. Возможности мобильных устройств изначально ограничены физическими размерами и временем автономной работы (остальные ограничения, в основном, вытекают из этих двух). Мобильное приложение разрабатывается с учетом этих ограничений, но так как софт для телефона должен быть адаптирован для использования на конкретной модели, то процесс разработки усложняется. Разделив мобильное приложение на клиентскую (представление данных) и серверную (прикладная логика) части, разработчик получает следующие возможности:

• урезанная по функционалу клиентская часть получается менее требовательной к ресурсам;
• для поддержки новых устройств нужно адаптировать только фронт-энд, не затрагивая прикладную логику;
• изменения в программе (расширение функциональности, исправление ошибок и т. п.) выполняются на сервере приложений и распространяются на всех клиентов.

Клиенты могут взаимодействовать с приложениями через API сервера (Java-клиент <-> контейнер сервлетов <-> сервлет). Большую гибкость и универсальность представляет взаимодействие через сторонние сервисы, в первую очередь - через веб-сервер.

Понятие сервера приложений традиционно связывают с платформой Java, указывая на то, что сервер Java-приложений представляет реализацию спецификации сервлетов, возможно в виде JSP, и еще некоторые сервисные услуги, в первую очередь соединение с базой данных.

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

Поэтому, чтобы ответить на вопрос, является ли (и в какой степени) некое сервисное ПО сервером приложений, стоит сравнить его заявленные функции со списком атрибутов, присущих этой категории:

• Предоставляет модель контейнера для приложений.
• Предоставляет сервисные услуги для программ.
• Обеспечивает управление приложениями и/или представляет средства их разработки.
• Соответствует индустриальным спецификациям и стандартам.
• Добавим сюда же обслуживание веб-страниц, ввиду реальной востребованности технологий на основе WWW.

Реализации

По приведенным признакам в рассматриваемую категорию попадают, например, традиционные терминал-серверные системы, технология CGI, контейнеры Java-сервлетов и др.

Унаследованные решения

Серверы терминалов представляют среду для удаленного выполнения программ, в качестве которой выступает сама операционная система. Доступ к ним осуществляется по протоколам удаленного управления (telnet, ssh, RDP, VNC и т. п.) из клиентского ПО (эмулятор терминала, средства управления удаленным рабочим столом и т.п.). Управление запущенной программой выполняется через эмулируемый на клиенте пользовательский интерфейс (текстовый или графический) операционной системы. На серверной стороне взаимодействие программ с ОС реализуется через системные вызовы. Управление также осуществляется средствами операционной системы. Разработка может вестись на любом языке, доступном в конкретной ОС.

Общий шлюзовый интерфейс (CGI) - технология доступа к приложениям через веб-сервер. Отличия от сервера терминалов здесь в том, что пользовательский интерфейс предоставляется в виде веб-страниц. Запросы веб-клиентов, обращенные к программам, размещенным в выделенном каталоге (как правило cgi или cgi-bin) перенаправляются на их вход через стандартный поток ввода (stdin). Результаты выполнения в виде гипертекста приложение возвращает веб-серверу через stdout.

Серверы Java-приложений

Платформа Java является индустриальным стандартом, позволяющим создавать из унифицированных компонентов интероперабельные программные решения для самых разных систем, в которых может быть запущена виртуальная машина Java (JVM).

Контейнер сервлетов - один из архитектурных компонентов J2EE, представляющий окружение для выполнения сервлетов. Сервлет - это Java-приложение, выполняющееся на стороне сервера (в отличие от апплета). Контейнер сервлетов может работать как полноценный самостоятельный сервер, но чаще используется (интегрируется) совместно с другим серверным ПО. Обеспечивает обмен данными между сервлетом и клиентами, берёт на себя выполнение таких функций, как создание программной среды для функционирующего сервлета, идентификацию и авторизацию клиентов, организацию сессии для каждого из них.

Концепция сервлет-контейнера позволяет создавать как универсальные, так и специализированные серверы приложений (например, для мобильных сервисов).

Примером реализации контейнера сервлетов является Apache TomCat, который используется в таких серверах приложений как Apache Geronimo, JBoss, GlassFish, IBM WebSphere Application Server (WAS).

Другие решения

Компания Microsoft представляет собственные решения для поддержки бизнес-логики и сервисной инфрастуктуры на основе ОС Windows Server и технологии.NET Framework. Основным средством разработки является язык C#.

Язык python, получивший популярность во многом благодаря Google, является основным средством разработки для сервера веб-приложений Zope.

Для сценариев на языке PHP, широко используемом для создания веб-сайтов, компания Zend Technologies (разработчик самого языка PHP) создала сервер приложений Zend Server.

Серверы приложений: плюсы и минусы

Преимущества

Целостность кода и данных

Размещение бизнес-логики на выделенном сервере или ограниченном числе серверных компьютеров гарантирует доступ к обновленному и модернизированному ПО для всех клиентов. Это исключает риск доступа и управления данными из устаревших и, возможно, несовместимых программ.

Централизованное управление

Изменения в конфигурации прикладных программ, такие как, например, смена сервера баз данных, выполняются централизованно.

Безопасность

Централизованные средства, через которые поставщик услуг (сервис-провайдер) может управлять доступом к данным и компонентам приложения, позволяют выполнять проверку подлинности потенциально ненадежных клиентов в среднем слое и не затрагивать уровень базы данных.

Производительность

Сервер приложений может решать задачи балансировки сетевого трафика и распределения нагрузки между другими физическими серверами системы.

Общая стоимость владения

Совокупность перечисленных выше преимуществ, а в дополнение к ним перераспределение затрат на оборудование с клиентской на серверную сторону, может привести к экономии средств для организации. Так же на снижении общей стоимости владения может отразиться практика аренды программного обеспечения. Справедливости ради нужно отметить, что стоимость самого серверного ПО, а также затраты на его внедрение и сопровождение могут быть весьма высокими.

Недостатки

Централизация

Системы, построенные на основе сервера приложений, имеют один основной недостаток, присущий всем централизованным решениям - «падение» сервера приведет к недоступности программ для всех клиентов. К тому же эффекту приведут и неполадки в сетевом подключении.

Защита информации

Эта проблема, в принципе, актуальна для любых сетевых решений, использующих для передачи данных инфраструктуру публичных сетей.

Постоянный адрес этой страницы:

Сначала были Файл-сервер и Принт-сервер, довольно быстро к ним добавился Почтовый сервер. Не успели мы как следует привыкнуть к Web-серверам, как судьба подкидывает нам новые испытания - изволь осваивать Сервер Приложений. Особая проблема возникает при переложении понятия на русский язык. Тут уже путаница становится просто невообразимой. Искушенный читатель может с досадой воскликнуть - «Э! Да что же тут нового? Это же обычная многозвенка: сервер приложений, сервер базы данных и клиент!» - и прекратить чтение. Однако, Сервер Приложений - это Федот, да не совсем тот.

Итак, начнем по порядку, чтобы и не столь искушенный читатель понял, что имеется в виду. Предмет наших размышлений - это Application Server или Сервер Приложений. Ныне модно в качестве предисловия давать рекламу наоборот - перечислять то, чего в написанном нет; то ли из ложной скромности, то ли следуя завету Микеланджело: убирать все лишнее. Поэтому вы не найдете в этой статье серьезного доказательного сравнения технических реализаций Серверов Приложений, описания методов и приемов работы с этими реализациями, примеров файлов, листингов и кусков кода - приведен лишь список источников, в которых можно все это отыскать. Здесь же займемся более общими, но не менее увлекательными вопросами - что такое Сервер Приложений, зачем это нужно, как это покупать и выбирать и как с этим работать. Предвижу недовольство читателей, которые убеждены в том, что их не пускают на «кухню» и, следовательно, в приготовленном кушанье будет намешано неизвестно что. Приведу краткие соображения, почему следует читать и писать не только сугубо технические статьи. Прежде чем готовить еду, надо определить что - суп или гарнир, легкий ужин или обед для званых гостей, надо составить меню, заготовить продукты, выработать план изготовления, а уже потом приступать к поварскому ритуалу. Какой этап важнее - на этот предмет существует известная сказка, в которой плотник, портной и кукольник спорят, кому должна принадлежать сделанная ими кукла. Насколько я помню, в сказке побеждал кукольник, поскольку именно он вдохнул в куклу жизнь. В этом смысле таким волшебником несомненно является программист-разработчик. Нимало не преуменьшая его роль, я все-таки замечу, что современные программные приложения всегда плод коллективной работы. Поэтому провал или даже неудовлетворительное выполнение любого промежуточного этапа могут безнадежно загубить все дело.

Но, довольно реверансов. Нас ждет Сервер Приложений, которому просто не терпится убедить вас в том, что без него не обойтись.

Как ни грустно опять обращаться к знакомой всем заинтересованным лицам истории компьютерных технологий, без этого Сервер Приложений предстанет перед нами бродягой без роду и племени. Но я постараюсь быть краткой, тем более что истории то всего лет 50, правда, очень стремительных. Основные этапы этой истории приведены на рис. 1.

Первая эра - эра эксклюзивного «монолита», когда компьютерные программы, или потом, пакеты программ, выполнялись на одном компьютере. Особого выбора у потенциальных потребителей программных продуктов тогда не было - или сам разрабатывай, или заказывай у опытных людей. Тогдашние операционные системы не баловали богатством возможностей - работает приложение на компьютере - и хорошо. Оно могло работать годами, выполняя раз навсегда закрепленные функции, и все были довольны. Это время часто называют и «эрой мэйнфреймов», хотя именно мэйнфреймы подошли вплотную к «тихой революции». От них появилась возможность приставить к одному серверу несколько «глаз» - терминалов, которые позволили плавно перейти в «клиент-серверную эру». Вот тут то и появляется служака «сервер». Сервер работает, служит, выполняя задания его величества клиента. Клиент от простенького «застенчивого» терминала вырастает до важного и значительного повелителя. Нынешний революционный момент характеризуется тем, что серверы не могут, а клиенты не хотят существовать по-старому. Первые не могут справиться с обилием поставленных перед ними требований, а вторые недовольны качеством обслуживания их запросов. Выход - в дальнейшей специализации. То, что пыхтя и отдуваясь выполняет несчастный сервер, теперь будет распределено на множество серверков - компонентов, каждый из которых успешно выполняет свою функцию. В такой компании клиенты превращаются в равноправные компоненты, чья задача - представительство функциональных сотоварищей (других компонентов) для пользователя, сидящего перед дисплеем.

Раз уж мы ввели строительный термин - монолит, то приведем строительно-архитектурную параллель. Первая - монолитная эра, эра дольменов и кромлехов, отдельных решений, автоматизирующих конкретные производственные задачи заказчика. Опыта еще мало - каждое сооружение в некотором смысле произведение искусства. Вторая эра - однотипные поселения, каждое их которых характеризуется зaмком (сервером) и постройками попроще вокруг (клиентами). И если простые постройки не представляют большой архитектурной ценности, то замки - решения штучные и дорогостоящие. А переходим мы в эру массовой застройки, когда «строительство» программных приложений поставлено на поток. И сколько бы мы ни ругали такую застройку, именно этот способ позволяет обеспечить жильем - программными приложениями, всех желающих за разумную цену и в реальные сроки.

Типовые современные дома обычно строятся из блоков или панелей. Так и современные программные приложения строятся или, скорее, будут строиться из компонентов. (Компонент - самостоятельный программный продукт, поддерживающий объектную парадигму, реализующий отдельную область бизнес-логики и умеющий взаимодействовать с другими компонентами с помощью открытых интерфейсов.) Такая технология позволит ответить на самые острые проблемы компьютерного мира - сокращение времени разработки программного приложения, облегчение процесса внедрения и поддержка гибкости внедренного решения. На рис. 2 изображены этапы жизненного цикла программного приложения.

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

Под лозунгом «Быстрее, легче и гибче» и создаются современные бизнес-компоненты. Преимущества подобного подхода можно выразить в длинном списке: масштабируемость, стабильность, управляемость, настраиваемость, гибкость, переносимость, возможность многократного использования. Но, к сожалению, чудес в жизни не бывает и, если сложностей и неурядиц убыло в одном месте, то в другом они как раз прибавились. Для того чтобы компоненты умели взаимодействовать, необходимо развитие «клея» - промежуточного программного слоя.

Итак, если со стороны бизнеса все красиво, как на затейливом персидском ковре, то зато на изнанке - уйма всяких узелков и зацепок. Последние годы мировое программное сообщество усиленно пытается внести порядок в эту изнанку, в чем, надо сказать весьма преуспело. Основная возможность здесь - стандартизация компонентов, приведение их к единой природе. Блоки здания должны быть сопрягаемы. Нити ковра должны быть из близких материалов. Идея здесь достаточно проста - внешние интерфейсы компонентов должны быть описаны в едином стиле - на одном и том же языке. Поэтому два известных на сегодняшний день стандарта, CORBA и COM+ создали свои варианты IDL - Языка Описания Интерфейсов. CORBA, COM+ и технология Java, которая, естественно, использует для описания интерфейсов язык Java, предлагают близкие подходы к методу взаимодействия компонентов. На основе описания внешних интерфейсов создаются прокси (заместители) для клиента и сервера, которые позволяют им связываться друг с другом в реальном времени. Прокси для клиента принято называть стабом, а прокси для сервера - скелетоном. (Мы договорились - я не претендую на изложение технологий, а только даю краткий взгляд на них. Поэтому, в частности, не касаюсь возможностей динамического взаимодействия компонентов в технологии CORBA, когда внешние интерфейсы не определены на момент компиляции системы и появляются дополнительные динамические элементы.)

После стандартизации интерфейсов, мировое компьютерное сообщество перешло на следующий уровень стандартизации - самих компонентов. Из рис. 3 понятно, что я имею в виду под следующим уровнем стандартизации - все дальше от «железа», все ближе - к пользователю. В технологии CORBA это:

• ССМ (CORBA Component Model)- компонентная объектная модель, компонентное развитие модели бизнеса ВОМ - Business Object Model;
• BOCA (Business Object Component Architecture) - принципы архитектуры компонентных систем, развитие OMA (Object Management Architecture) на вышележащий уровень стандартизации;
• CDL (Component Definition Language)- язык определения компонентов, развитие IDL.

Разработка этих стандартов продвигается, правда, не так быстро, как хотелось бы всем заинтересованным сторонам. Но признанным героем на поле стандартизации компонентов стала технология компании Sun - Enterprise Java Beans (EJB). Возможно причина ее успеха в том, что в «семейном кругу» одного языка программирования намного проще решить вопросы взаимодействия. Тем более языка молодого и резвого, который многие проблемы, такие как вызов удаленных методов (RMI - Remote Method Invocation), умеет решать сам. Не иcключено, что универсальные цели консорциума OMG, развивающего технологию CORBA, - объединить компоненты, написанные на разных языках программирования, функционирующие на разных системах и разных компьютерах в разных точках земного шара, являются в данном случае некоторым тормозом. В дальнейшем мы увидим как две технологии, сомкнувшись, отбросив амбиции, дают замечательный результат на радость всем заинтересованным сторонам.

Что же такое этот «бин» (beаn - боб) и почему, стремительно выскочив как джин из бутылки в компьютерный мир, он уже завоевал такую популярность? Если перевести определение Sun как можно ближе к оригиналу - то «это модель для создания и развертывания серверных компонентов многократного использования, написанных на языке Java.» Продолжим вместе с Sun расплетать косу этого определения, - «компоненты - это заранее разработанные куски программного кода, которые могут быть установлены в работающие прикладные системы». Если классы Java образуют компонентную модель для проектирования приложений в технологии Java, то Java Beans логически развивает эту модель на следующем уровне интеграции создания автоматизированных систем и абстрагирования от процесса программирования - стадии внедрения. По сути, это переход от разработки приложения под заказ из готовых программных компонентов к сборке из готовых ЕJB действующих компонентов. Если раньше дома складывали из кирпичей, то теперь - из комнат-секций. Cлово Enterprise в названии Enterprise Java Beans означает новую ступень технических задач, стоящих перед программными приложениями. Такие задачи привычны для приложений уровня Предприятия: поддержка распределенности, службы именования, транзакций, безопасности, уведомлений-сообщений, долговременного хранения, и т.д. Неудивительно, что этот список напоминает список Служб технологии CORBA.

С точки зрения разработки, EJB представляют собой Java-классы специального типа вместе с описателем-паспортом бина и параметрами среды функционирования, которые бин умеет обрабатывать. Описатель бина (Deployment Descriptor) в свою очередь представляет собой XML-файл, в котором содержатся правила, связанные с управлением бином, например, права доступа пользователей к бину. Несколько бинов могут объединяться, образуя приложения, Java-апплеты и новые бины.

Рис. 4. Контейнер Enterprise Java Beans

По технологии EJB бобы-бины размещаются в стручке - контейнере (рис. 4) На контейнер возложены обязанности по защите бинов и поддержке их взаимоотношений с внешним миром: регистрация-прописка объектов, обеспечение для них внешних интерфейсов, создание и разрушение реализаций этих объектов, охрана безопасности, управление их состояниями и координация транзакций. В технологии не определено, как конкретно должен быть реализован контейнер. Это могут быть как многопоточные процессы на отдельном сервере, в которых выполняются бины, так и законченные программные приложения, которые можно переносить или распределять между серверами и/или процессами. Клиентские бины обрабатываются внутри виртуальных контейнеров, таких как Web-страницы, формы, составные документы, и т.д.

В технологии определены два основных типа бинов. Session Beans - сеансы клиент-серверного взаимодействия отрабатывают действия клиента, например, запись в базу данных, выполнение вычислений, и т.д. Это окна клиента в мир программных приложений. Они, в свою очередь, также бывают двух типов:

• Stateless session - не умеют сохранять свое состояние и существуют только на протяжении текущего сеанса. В случае сбоя сеанс не может быть восстановлен;
• Stateful session - сохраняют свое состояние; сеанс может быть восстановлен.

Entity Bean - компоненты объектного представления данных, размещаемых в хранилище. Entity Bean транзакционны и восстанавливаемы. Каждая их реализация имеет уникальную метку, называемую «первичным ключом» (Primary Key) по аналогии с таблицами баз данных. В свою очередь эти бины делятся на две группы по способу определения где, в каком хранилище и как хранятся данные:

• Bean-Managed Persistence - самостоятельные бины, управление хранением осуществляется на уровне бинов;
• Container-Managed Persistence - «опекаемые» бины, чьим хранением заправляет контейнер.

Кроме класса, реализующего функциональность бина, в него входят два обязательных класса, реализующие два типа интерфейсов:

• Home Interface - доступ к «домашним» службам бина, таким как начало или отбой для Session Bean или поиск Entity Bean. Этот интерфейс реализует все службы жизненного цикла компонента и позволяет контейнеру управлять и руководить его поведением;
• Remote Interface - доступ к бизнес-службам бина.

Клиентские приложения общаются с бинами через контейнер, который открывает наружу оба интерфейса бина: Home и Remote. С помощью первого открывается сеанс или находится нужный бин, а с помощью второго - осуществляется отработка действий клиента в Session или транзакционная механика обработки Entity.

Итак, повторим идею технологии с прикладной точки зрения. Прикладная бизнес-логика приложения делится на изолированные бизнес-объекты, каждый из которых реализуется в виде EJB. Они устанавливаются на Сервере Приложений или EJB Сервере и реализуют запрашиваемую логику для клиента (локального или удаленного). Давайте прямо сейчас, при первом появлении понятия Сервер Приложений в технологии Java, развеем непонимание, о котором уже говорилось в начале статьи. Написав оба слова, составляющие понятие, с заглавных букв, мы магическим образом преобразовали сервер приложений, реальную машину из корпуса, начинки и кабелей, в программное приложение.

Обратимся вновь к интерпретации Sun. Под Сервером Приложений в технологии Java понимается программное приложение, обеспечивающее оптимальную среду для выполнения EJB. Сервер Приложений занимается «коммунальным хозяйством» дома - программной системы. На его руках надзор за системными ресурсами, такими как процессы, потоки, память, связь с базами данных, сетевые отношения, выравнивание загрузки распределенных узлов. Кроме этого важнейшая обязанность Сервера Приложений заключается в предоставлении cle;, компонентам.

Еще раз хочу подчеркнуть, что технология EJB, впрочем, как и технология CORBA не предоставляет готовые программные решения - контейнеры, Сервера Приложений, а только стандарты на такой тип программного обеспечения.

Стандарты - единственная возможность обеспечить некоторый порядок в бурно развивающемся компьютерном мире. Стандарты необходимы всем трем заинтересованным сторонам в области информационных технологий: разработчикам, потребителям-заказчикам и промежуточному звену - консультантам, интеграторам, продавцам. Первым - для поcтавки на рынок конкурентоспособных, жизнестойких решений, вторым - как средство борьбы с «зоопарком» программных систем, третьим - как возможность строить гибкие, интегрированные программные среды для своих заказчиков.

Стандарты продолжают захватывать все новые области информационных технологий. Но, если в сетевых технологиях стандарты полностью прижились, то в области программных приложений они еще только набирают силу. Понятны опасения специалистов использовать в собственных решениях «неправильный» стандарт, который зачастую, невзирая на грамотные технические решения, заложенные в его основу, не идет дальше прекрасных инициатив и не получает развития. Выбирая дорогу, всегда есть опасность оказаться в тупике. Именно поэтому стоит внимательно читать указатели (в смысле дорожные знаки) и прислушиваться к мнению мирового сообщества. Серверы Приложений уже сейчас имеют реализации от большинства крупных производителей программных систем (компании Inprise, Oracle, Sybase, Sun, BEA, Iona, IBM). Кроме того, в данной области архитектуры программных приложений пока не появилось ни одного достойного конкурента. Так что стиль пока единственный - Сервер Приложений.

Если посмотреть на Серверы Приложений глазами конечного пользователя, то они представляют собой основные несущие конструкции сооружения под названием многозвенная распределенная компонентная программная система. Именно Серверы Приложений поставляют бизнес-компоненты и обеспечивают необходимый уровень системных служб для этих компонентов, т.е. всю коммунальную систему жизнеобеспечения. Приложения, которые наш Сервер предоставляет клиентам, могут располагаться где угодно, причем эти приложения могут даже не знать, где хранятся данные, с которыми они работают - на каком сервере и в какой базе данных. Для клиентов Сервер Приложений открывает и закрывает сеансы. Для приложений - позволяет настраивать системные службы, из которых важнейшими являются служба долговременного хранения, политика хранения компонентоа Entity Beans, служба транзакций и служба безопасности.

«А надо ли городить огород?, - спросит недоверчивый читатель. - Зачем мне такое дополнительное ПО для моего сугубо конкретного программного приложения?»

Огород, может быть, городить и не надо, а обеспечить газом, электричеством и горячей водой наш блочный дом, программное приложение - необходимо. Да и надежный кодовый замок на входной двери не помешает. Конечно, можно предоставить решать эти проблемы самим жильцам. Пусть каждый в одиночку кипятит воду и укрепляет входную дверь. Тогда уж лучше просто влезть на дерево (я никоим образом не имею в виду службу каталогов NDS) и кушать бананы (не путайте с Baan).

Чтобы постройка программного приложения не напоминала возведение Вавилонской башни, в технологии EJB расписано, кто именно должен принимать участие в проекте. Комплексная бригада строителей здания состоит, по представлению компании Sun, из следующих профессионалов.

Архитектор

Поставщик серверной платформы (EJB Server Provider) - специалист в области распределенной платформы и служб. Он предоставляет инфраструктуру разработки и среду выполнения для программных приложений.

Конструктор

Поставщик контейнеров (EJB Container Provider) - эксперт в области распределенных систем, системной безопасности и поддержки транзакций. Он обеспечивает системный уровень контейнеров, то есть системную оболочку для одного или более компонентов - Enterprise Bean.

Снабженец

Поставщик бизнес-компонентов (Enterprise Bean Provider) - аналитик в функциональной области, который реализует бизнес-компоненты как разработчик или подбирает готовые.

Монтажник

Компоновщик Приложений (Application Assembler) - также эксперт-функционал, собирающий программное приложение из строительных блоков - бизнес-компонентов. Его взгляд на соответствующий бизнес должен быть более общим и универсальным, чем у Снабженца - Поставщика бизнес-компонентов.

Прораб

Внедренец (Deployer) - специализируется в установке приложений. Он настраивает приложение на реальную среду.

Управдом

Администратор системы (System Administrator) - обеспечивает работоспособность системы на этапе эксплуатации.

Конечно, то, что компания Sun описала именно такие роли, не означает, что любой проект, связанный с Enterprise Java Beans обязательно требует одного и только одного указанного специалиста и именно такой состав комплексной бригады. Да и найти, скажем, готового поставщика контейнеров не так-то просто. Что совершенно необходимо - так это не упустить специфические для компонентного проекта моменты: выбор архитектуры и способы реализации системных служб, определение структуры и поведения контейнеров и проработка вопросов внедрения (развертывания).

Завершив экскурс в EJB, можно привести определение Сервера Приложений «с большой буквы». Сервером Приложений называется программный продукт, поставляющий среду выполнения для прикладных компонентов, расположенный между клиентом - с одной стороны и данными и прикладными программами - с другой, который может обеспечить интеграцию различных источников данных и прикладных ресурсов и предоставить компонентам необходимые для них сервисы.

Разочарованный читатель возмутится: «Зачем же нам объясняли про EJB, если в определении про них нет ни слова!» Попробую пояснить. Я намеренно привела универсальное определение Сервера Приложений, которое относится ко всем типам компонентов (CORBA, EJB, COM+). Серверы Приложений, зародившись внутри технологии EJB, оказались столь удобны, что достаточно уверенно продвигаются как единое решение для всех компонентных технологий. Реализации Серверов Приложений уже умеют работать с разными компонентами. В качестве примера приведу Application Server компании Inprise, который можно успешно использовать в среде компонентов EJB и CORBA. Другой наблюдаемый процесс - смыкание технологий Java и CORBA. С небольшой долей натяжки можно считать, что EJB могут иметь двойное гражданство, а именно представлять собой еще и CORBA-объекты. С моей точки зрения, поддержка CORBA является необходимым условием для конкурентности реализации Сервера Приложений. Ведь из всех перечисленных технологий только эта поддерживает Унаследованные Системы - функционально пригодные, но технически устаревшие. Если считать парк автоматизации современного предприятия или компании некоторым поселением - деревушкой или городком, создаваемая интеллектуальная компьютерная среда должна включать уже существующие постройки. Одинаково неправильно требовать сноса существующих зданий или не обращать на них внимания.

Другой аспект выбора реализации Серверов Приложений заключается в функциональности, которая наиболее приоритетна. Попробуем разделить Серверы приложений на группы.

1. Интеграционный Сервер Приложений. (Application -integration-centric application server)

Основная задача такого Сервера - интеграция Бизнес-приложений в единую интеллектуальную среду. Такие Серверы особенно актуальны для организации приложений, связанных с задачами типа Supply Chain (Цепочки Поставщиков) и электронной коммерции. К таким серверам относятся реализации крупнейших поставщиков брокеров объектных запросов - компаний Inprise и Iona.

2. Информационный Сервер Приложений (Data-centric application server)

Деятельность такого сервера сконцентрирована на манипулировании данными. В качестве хранилищ могут выступать произвольные приложения, которые, в частности, не обязательно представляют собой реляционные базы данных и, уж тем, более объектные. Такие серверы берут на себя организацию представления распределенных данных, хранящихся в различных источниках, в объектной парадигме. Естественно, Oracle поставляет серверы именно такого типа.

3. Обрабатывающий Сервер Приложений (Processing-centric application server)

Центральной заботой таких серверов является обеспечение специфической бизнес-логики. Например, сервер, реализующий распределенные вычисления, или сервер ERP-системы. К таким реализациям относится IBM Websphere.

4. Управляющий Сервер Приложений (Rules-based application server)

Такие серверы являются подмножеством Обрабатывающих Серверов Приложений, но в отличие от них сконцентрированы на выполнении определенных бизнес-правил. Они ориентированы прежде всего на область электронной коммерции. Примером таких серверов является реализация от компании Vision Software.

5. Сервер XML (XML Server)

Этот сервер представляет собой подмножество Информационного сервера, с той лишь разницей, что в качестве хранилищ данных выступают XML - документы. С другой стороны, такой сервер может представлять собой подмножество Интеграционного сервера, в котором в качестве механизма интеграции выбран XML. Известна реализация такого сервера от компании Bluestone Software.

Не следует думать, что разделение Серверов Приложений по группам такое четкое. Наиболее интересные экземпляры Серверов Приложений гармонично сочетают в себе достоинства различных групп. Кроме того компании-разработчики активно развивают свои продукты. А каждая новая версия, естественно, богаче предыдущей.

Предвижу следующий вопрос читателей: - « А это уже где-нибудь работает?» Ответ - «Да!». Особенно востребованы Сервера Приложений во всем, что касается использования Internet. И за счет поддержки распределенности, возможностей выравнивания загрузки, отслеживания распределенных неоднородных транзакций, управления безопасностью и многих других своих возможностей. Именно эти интеллектуальные приложения находят в Серверах Приложений могучую опору.

Рис. 5. Java 2 Enterprise Edition

Вскользь упомяну о следующих усилиях по созданию технологии компонентного программного обеспечения, снова связанных с Java. Это J2EE (Java 2 Enterprise Edition) - стандарт для многозвенных систем уровня предприятия, прикладная платформа, обеспечивающая взаимодействие Enterprise Java Beans, Java Server Pages, апплетов и сервлетов. рис. 5 в точности иллюстрирует то, как это выглядит у компании Sun.

Средства взаимодействия компонентов располагаются в нижней части рисунка. J2EE впервые стандартизовала выполнение родного для Java протокола удаленных вызовов методов через Internet - IIOP (Internet InterOrb Protocol). Таким образом, к сотрудничеству между CORBA и Java добавился еще один пункт. Серверные компоненты заключены в контейнеры, взаимодействующие с помощью специальных коннекторов. На уровне контейнеров задаются системные сервисы: Транзакций, Сообщений и Почты. На верхнем уровне находится API-интерфейс и Средства управления. Сказать об этой технологии в контексте Серверов Приложений меня вынудило не только то, что этот стандарт является логическим развитием технологии EJB, в которой впервые определился наш герой, но и то, что уже появляются Серверы Приложений, удовлетворяющие новому стандарту. Я имею в виду уже упоминавшийся Application Server (Inprise).

Но, стоп, боюсь, что Вы уже устали от обилия технологий и нагромождения стандартов? Если да - то тогда обратитесь к рис. 6, где я попыталась свести все воедино.

В защиту всего этого хозяйства хочу отметить, что, говорят, наши предки -обезьяны прекрасно жили на деревьях и, если и сплетали себе нечто вроде гнезд, но ни один из нас не согласился бы там жить постоянно, разве что для того, чтобы испытать захватывающее приключение. Так и программные приложения постепенно слезли с деревьев и начали строить себе дома. А если говорить о стандартах в строительстве, то их все равно намного больше, чем на сегодняшний день существует в информационных технологиях. В утешение хочу добавить, что наши стандарты неплохо уживаются друг с другом. По крайней мере, учатся это делать. Как пример, хочу обратить ваше внимание на неоднократное упоминание лакомого современного стандарта XML в этой статье, которая вроде бы написана совсем о других стандартах.

Легче ли создавать программные системы с помощью Сервера Приложений? Я бы покривила душой, если бы однозначно ответила - «да», хотя мне и очень хочется это сделать. Как всяким инструментом, к тому же непростым, им надо научиться пользоваться. Его нужно применять только в определенных условиях, как по инфраструктуре, так и по программному обеспечению. Отдельный вопрос - какую именно реализацию Сервера Приложений следует использовать. Сервер Приложений - верный друг, но только для заботливого и грамотного хозяина.

Об авторе

Марина Аншина - сотрудник отдела системной интеграции компании «ТопС, Системный Интегратор». С ней можно связаться по электронной почте по адресу: [email protected]

Моральный кодекс молодого строителя программного обеспечения - Сервера Приложений

Источники