Сервер приложений - не пуп Земли?

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

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

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

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

Рис.1. Развитие прикладной архитектуры компьютерных систем

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

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

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

Рис. 2. Жизненный цикл информационных систем

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

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

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

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

Рис. 3. Стандарты в программных приложениях

• ССМ (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 является необходимым условием для конкурентности реализации Сервера Приложений. Ведь из всех перечисленных технологий только эта поддерживает Унаследованные Системы - функционально пригодные, но технически устаревшие. Если считать парк автоматизации современного предприятия или компании некоторым поселением - деревушкой или городком, создаваемая интеллектуальная компьютерная среда должна включать уже существующие постройки. Одинаково неправильно требовать сноса существующих зданий или не обращать на них внимания.

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

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

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

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

Центральной заботой таких серверов является обеспечение специфической бизнес-логики. Например, сервер, реализующий распределенные вычисления, или сервер 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, где я попыталась свести все воедино.

Рис. 6. Стандарты распределенных программных систем

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

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

Об авторе

Марина Аншина — сотрудник отдела системной интеграции компании «ТопС, Системный Интегратор». С ней можно связаться по электронной почте по адресу: marinaa@tops-msk.com

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

Источники