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

• Первый способ заключается в том, что при установке веб-сервера один из каталогов специально выделяется для хранения сценариев. Обычно такой каталог получает имя cgi-bin (или Scripts для веб-сервера IIS). В этом случае, если клиент запрашивает файл из каталога cgi-bin , сервер воспринимает такой запрос как команду на запуск сценария. Файлы из других каталогов интерпретируются как HTML-документы.
• Второй способ использует расширение файла. При настройке сервера указывается, что файлы с определенными расширениями содержат коды сценариев.

Идентификация по расширению используется относительно редко. Чаще всего все сценарии помещаются в cgi-bin , /Scripts или в другой каталог, специально выделенный для их хранения.

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

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

НТТР/1.0 200 OK

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

Самый естественный формат для браузера - формат HTML . Результаты работы сценария обычно оформляются в виде веб-страницы, т.е. возвращаемые данные следует дополнить дескрипторами HTML . Таким образом, ответ CGI -сценария клиенту обычно выглядит так:

Content-type: text/html ответ сценария ……………………

Обратите внимание на пустую строку после выражения Content-type: text/html . Она обязательно должна присутствовать в ответе, в противном случае клиент воспримет все последующие данные как продолжение заголовка.

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

Для вызова данного сценария достаточно включить в веб-страницу следующий фрагмент HTML -кода:

• Если атрибут method имеет значение " GET ", строка параметров передается вместе с URL вызываемого сценария. Разделителем между URL и строкой параметров является символ " ?".
• Если атрибут method имеет значение " POST ", строка параметров передается в теле HTTP-запроса.

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

Если атрибут METHOD дескриптора имел значение " GET ", строка параметр передается серверу в качестве значения переменной окружения QUERY_STRING .

При использовании метода POST данные доставляются сценарию по-другому. Они передаются через стандартный поток ввода (STDIN). Чтобы сценарий смог определить, сколько символов следует читать из стандартного ввода, веб- сервер устанавливает значение переменной окружения CONTENT_LENGTH , равным длине строки параметров.

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

Таким образом, в простейшем случае, чтобы выполнить обработку строки параметров, достаточно знать назначение трех переменных окружения:

Сценарии

К основным достоинствам разработки приложений на стороне веб-сервера в форме сценариев можно отнести следующие:

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

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

В плане быстродействия сценарные языки можно разделить на:

• Языки динамического разбора (например, command.com). Интерпретатор считывает инструкции из файла программы минимально требующимися блоками, и исполняет эти блоки, не читая дальнейший код.
• Предварительно компилируемые (например Perl). Вначале считывается вся программа, затем компилируется либо в машинный код, либо в один из внутренних форматов, после чего получившийся код исполняется.

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

Сначала были Файл-сервер и Принт-сервер, довольно быстро к ним добавился Почтовый сервер. Не успели мы как следует привыкнуть к 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]

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

Источники

«94 Лекция 6 Организация распределенных вычислений с использованием серверов приложений Серверы приложений (CП) являются одной из ключевых составляющих...»

Организация распределенных вычислений с использованием

серверов приложений

Серверы приложений (CП) являются одной из ключевых

составляющих IT-инфраструктуры значительной части современных крупных

предприятий. Если компания нуждается в интеграции ее

внутрикорпоративных приложений с корпоративным Web-сайтом и Webприложениями, а также в надежном и быстром доступе к данным и

приложениям со стороны собственных сотрудников, партнеров и клиентов,

она рано или поздно сталкивается с необходимостью внедрения одного или нескольких серверов приложений.

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

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

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

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

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

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

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

Эти компоненты могут представлять собой:

COM-объекты;

CORBA-объекты;

компоненты Enterprise JavaBeans.

В функции сервера приложений входят:

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

обеспечение связи приложения с внешними ресурсами (включая базы данных, сети и другие приложения);

обеспечение качественной поддержки сервисов (доступность, надежность, безопасность, управление, производительность, масштабируемость);

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

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

В настоящее время серверы приложений являются основой многих корпоративных решений с повышенными требованиями к надежности, например приложений, связанных с электронной коммерцией, реализующих схемы «предприятие - потребитель» (business-to-consumer, B2C), «предприятие - предприятие» (business-to-business, B2B), «предприятие - сотрудник» (business-to-employee, B2E).

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

–  –  –

Говоря о корпоративных решениях, нельзя не отметить проблему интеграции как различных приложений внутри одного предприятия, так и приложений, используемых на разных предприятиях. Одним из общепринятых способов ее решения является реализация функций приложений, к которым нужен доступ извне, в виде Web-сервисов XML, и большинство производителей СП, СУБД и средств разработки приложений реализовали поддержку Web-сервисов и связанных с ними технологий.

–  –  –

Реализация функций приложений, в виде Web-сервисов XML Технологии и стандарты Сегодня на корпоративном рынке доминируют две архитектуры серверов приложений:

NET (представлена только в исполнении Microsoft);

Java EE (ранее известная как J2EE), предоставляемая множеством компаний (мультивендорная).

Но при этом серьезную конкуренцию лидерам составляют новые программные модели, такие как Spring Framework, PHP, Ruby on Rails, Apex Code, Plain Old Java Object (POJO).

Серверы приложений могут быть доступны пользователям:

в виде продуктов, устанавливаемых собственно внутри компаний, в качестве облачных сервисов, предоставляемых провайдером.

Для определения расстановки сил на рынке серверов приложений обратимся к данным исследовательской и консалтинговой компании Gartner, специализирующейся на рынках информационных технологий (ИТ).

Для оценки поставщиков какого-либо сегмента рынка ИТ, Gartner использует две линейные прогрессивные экспертные шкалы:

полнота видения (англ. completeness of vision), способность реализации (англ. ability to execute).

При этом, полнота видения откладывается на оси абсцисс, способность реализации - на оси ординат.

Каждый поставщик, таким образом, оказывается в одном из четырёх квадрантов плоскости, называемых:

лидеры (англ. leaders) - поставщики с положительными оценками как по полноте видения, так и по способности реализации, претенденты (англ. сhallengers) - поставщики с положительными оценками только по способности реализации, провидцы (англ. visionaries) - поставщики с положительными оценками только по полноте видения, нишевые игроки (англ. niche players) - поставщики с отрицательными оценками по обоим критериям.

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

По мнению Gartner, СП могут применяться в трех основных сценариях:

“временно-ориентированные” проекты - быстрая разработка и развертывание приложений в ответ на бизнес-требования, которые “не могут ждать”. В этом случае время реализации проекта является более важным, чем обеспечение доступности, масштабируемости и т. д.;

проекты “массового рынка” - не очень сложные прикладные системы, создаваемые небольшими ИТ-компаниями. Здесь важны такие параметры, как низкая стоимость, простота развертывания, поддержки и управления, надежность. Функциональность, масштабируемость и производительность не столь существенны;

“систематично-ориентированные” проекты - реализация критически важных для бизнеса корпоративных систем, рассчитанных на долгосрочный период эксплуатации (не менее трех лет). Наряду с разнообразной функциональностью тут необходимы надежность, безопасность, управляемость, масштабируемость, производительность. Ё Ниже в магическом квадранте рассматриваются поставщики продуктов класса CП масштаба предприятия (Enterprise Application Server – EAS) - таких, которые могут применяться в третьем сценарии. При этом отмечается, что многие такие решения можно успешно использовать и в двух других вариантах.

Рисунок 39 – Магический квадрант для СП масштаба предприятия

Как видим из квадранта:

Во первых: существует довольно большое число игроков, 28 компаний, некоторые из которых предлагают решения Open Source (свободное ПО, т.е.

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

Во-вторых: имеется ряд платформ, изначально ориентированных на вариант облачной вычислительной модели (в частности, нужно обратить внимание на Salesforce.com).

В-третьих: есть четко выделенная группа лидеров: IBM, Microsoft, Oracle, Red Hat (JBoss).

В-четвертых: видна острая конкурентная ситуация на рынке, которая предоставляет заказчикам широкий спектр выбора наиболее подходящих им решений. Gartner считает, что в ближайшее время здесь появятся новые серьезные игроки, такие как Google и Tibco, чьи решения (соответственно App Engine и Silver) находятся пока в режиме бета-тестирования.

–  –  –

Семейство ПО IBM WebSphere включает представительный набор EASпредложений (в т.ч. серию продуктов WebSphere Application Server -

WAS), который покрывает широкий диапазон требований заказчиков:

для “временно-ориентированных” проектов (WebSphere sMash), для массового рынка (WAS Community Edition, WAS Express), для масштабируемых корпоративных решений:

WAS Network Deployment, WebSphere Virtual Enterprise, CloudBurst Appliance, WebSphere Virtual Enterprise и др.

Некоторые из этих средств доступны в виде облачных сервисов IBM и Amazon Web Services EC2.

WAS-решения базируются в целом на стандартах Java EE и SOA, обеспечивая при этом поддержку разных моделей программирования.

Следует отметить, что IBM имеет в своем распоряжении мощные наборы средств разработки (Rational) и управления ИТ (Tivoli).

В то же время нужно сказать, что присутствие IBM на массовом рынке пока невелико. Выпущенный в середине 2008 года WebSphere sMash пока имеет относительно небольшую инсталлированную базу и весьма ограниченную поддержку со стороны третьих фирм. Продукты для облаков (WAS Hypervisor Edition, CloudBurst Appliance) появились относительно недавно, и пока в этой сфере IBM заметно отстает от лидеров. В целом Gartner отмечает, что стратегия IBM в области APaaS находится в ранней стадии своей реализации.

Microsoft

NET Framework вместе с Internet Information Server (оба являются интегрированными компонентами Windows Server) представляют собой полный набор функциональности EAS. Продукты семейства корпоративных серверов Microsoft Server System предназначены, как и другие СП, для создания и развертывания интегрированных корпоративных решений.

При относительно невысокой стоимости для этих серверов характерны:

поддержка XML,

–  –  –

По функциональности семейство серверов Microsoft Server System, в целом, заполняет практически все современные направления применения СП.

Все серверы семейства Microsoft Server System поддерживают управление COM-, COM+- и.NET-компонентами и доступны для операционных систем семейства Windows. Для других платформ эти продукты не выпускались и не выпускаются.

Из продуктов, входящих в семейство Microsoft Server System, к серверам приложений в традиционном понимании можно отнести:

сервер интеграции приложений Microsoft BizTalk Server, сервер сообщений и групповой работы Microsoft Exchange Server, сервер электронной коммерции Microsoft Commerce Server, масштабируемый сервер приложений для мобильной телефонии Microsoft Mobile Information Server, корпоративный портал Microsoft SharePoint Portal Server, сервер для управления информационным наполнением Web-сайтов Microsoft Сontent Manager Server;

сервер для управления крупными корпоративными проектами Microsoft Project Server.

Облачные предложения Microsoft реализованы в виде бета-версии Windows Azure Platform и недавно анонсированной технологии программируемой облачной платформы (xRM).

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

Но из достоинств Microsoft вытекают и ее слабые стороны - поддержка одной ОС и использование продуктов от одного поставщика. Из-за традиционной фокусировки на массовом рынке компания постоянно запаздывает с реализацией важных технологических инициатив (например, XTP (Extreme Transaction Processing - форма обработки транзакций в информационных технологиях) и SOA). При этом у Microsoft появился ряд очень серьезных соперников (Google, Salesforce, VMware), также ориентированных на массовый рынок, но в конкурентной борьбе использующих иные деловые и технологические модели.

Основу EAS-предложений Oracle составляет JEE-семейство Oracle WebLogic Server (WLS), полученное в результате приобретения в 2008-м компании BEA Systems, и собственная разработка Oracle Application Server (она еще поддерживается, но в стратегическом плане не развивается).

Кроме того, в группу EAS-продуктов входят:

средство разработки Oracle JDeveloper, инструмент Oracle TopLink;

средство для мониторинга, администрирования и управления Oracle Enterprise Manager.

В результате приобретения Sun Microsystems компания пополнила свой EAS-арсенал еще и целым портфелем EAS-технологий (в частности свободную среду разработки NetBeans), благодаря чему заняла ведущую роль в Java-сообществе.

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

На текущий момент в Oracle слабо представлены EAS-решения, ориентированные на массовый рынок, хотя приобретение Sun GlassFish частично заполнило эту брешь в спектре ПО Oracle.

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

Red Hat

JBoss EAS - это JEE5-совместимый JBoss Application Server (c апреля 2013 WildFly). Он доступен для бесплатной загрузки (без технической поддержки) или в составе пакета для предприятий в виде JBoss Enterprise Application Platform с оплатой поддержки по подписке.

Кроме того, у Red Hat имеется набор JBoss Enterprise SOA Platform, в него входят сервер приложений и целый ряд технологий поддержки SOA, включая решение JBoss ESB, предназначенное для интеграции различных систем, в том числе несовместимых.

Имеется также EAS-предложение JBoss Communications Platform, ориентированное на использование в телекоммуникационной отрасли.

Для Web-проектов предлагается JBoss Enterprise Web Server, включающий сервер приложений Apache Tomcat.

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

Все это ПО, бесплатное или получаемое по подписке, распространяется по лицензиям LGPL 2.x или Apache Software и доступно в виде исходных кодов или объектных модулей.

JBoss EAS имеет отличную техническую репутацию на рынке, Red Hat является явным лидером среди поставщиков открытых EAS-решений, ее продукты имеют огромную инсталлированную базу и великое множество партнеров и пользователей. Фактически это единственное Open Sourceсемейство на ИТ-рынке, которое на равных конкурирует с предложениями ведущих проприетарных вендоров. Но бизнес-стратегия Red Hat, нацеленная на повышение прибыльности подразделения JBoss, иногда имеет результатом замедление внедрения инженерных инноваций. Компания явно отстает от конкурентов в освоении передовых технологий, таких как XTP, событийное управление и облачные вычисления.

Архитектуры серверов приложений

Java Platform, Enterprise Edition Java Platform, Enterprise Edition, сокращенно Java EE (до версии 5.0 - Java 2 Enterprise Edition или J2EE) - набор спецификаций и соответствующей документации для языка Java, описывающей архитектуру серверной платформы для задач средних и крупных предприятий.

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

Основная цель спецификаций - обеспечить масштабируемость приложений и целостность данных во время работы системы. JEE во многом ориентирована на использование её через веб как в интернете, так и в локальных сетях. Вся спецификация создаётся и утверждается через JCP (Java Community Process) в рамках инициативы Sun Microsystems Inc.

Популярности JEE также способствует то, что Sun предлагает бесплатный комплект разработки, SDK (Software Development Kit), позволяющий предприятиям разрабатывать свои системы, не тратя больших средств. В этот комплект входит сервер приложений GlassFish с лицензией для разработки.

Актуальная версия Java EE (JEE) имеет номер 7.0.

При переходе на версию 5.0 к набору спецификаций добавилось несколько новых технологий и изменилось название спецификации с J2EE (Java 2 Platform, Enterprise Edition), на Java Platform, Enterprise Edition, сокращённо Java EE.

–  –  –

EJB – Enterprise JavaBeans – спецификация технологии написания и поддержки серверных компонентов, содержащих бизнес-логику.

JPA – Java Persistence API – предоставляет возможность сохранять в удобном виде Java-объекты в базе данных.

Сервлет – класс, расширяющий функциональные возможности сервера.

Сервлет взаимодействует с клиентами посредством принципа запрос-ответ.

JSP - JavaServer Pages -технология, позволяющая веб-разработчикам легко создавать содержимое, которое имеет как статические, так и динамические компоненты. По сути, страница JSP является текстовым документом, который содержит текст двух типов: статические исходные данные, которые могут быть оформлены в одном из текстовых форматов HTML, SVG, WML, или XML, и JSP элементы, которые конструируют динамическое содержимое.

JSTL – JavaServer Pages Standard Tag Library – «стандартная библиотека тегов JSP». Она расширяет спецификацию JSP, добавляя библиотеку JSP тегов для общих нужд, таких как разбор XML данных, условная обработка, создание циклов и поддержка интернационализации.

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

JSF - JavaServer Faces - компонентный серверный фреймворк для разработки веб-приложений на технологии Java, предназначенный для облегчения разработки пользовательских интерфейсов (ПИ) для JEEприложений. Подход JSF основывается на использовании компонентов.

Состояние компонентов ПИ сохраняется, когда пользователь запрашивает новую страницу и затем восстанавливается, если запрос повторяется.

JAX-WS - Java API for XML Web Services - это прикладной программный интерфейс языка Java для создания веб-служб.

JNDI - Java Naming and Directory Interface - это Java API, организованный в виде службы каталогов, который позволяет Java-клиентам открывать и просматривать данные и объекты по их именам.

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

JTA - Java Transaction API - Java API для транзакций. Определяет взаимодействие между менеджером транзакций и другими участниками распределенной транзакционной системы.

JAAS - Java Authentication and Authorization Service - реализация в языке программирования Java стандарта системы информационной безопасности PAM. Pluggable Authentication Modules (PAM, подключаемые модули аутентификации) - это набор разделяемых библиотек, которые позволяют интегрировать различные низкоуровневые методы аутентификации в виде единого высокоуровневого API. Это позволяет предоставить единые механизмы для управления, встраивания прикладных программ в процесс аутентификации.

JavaMail - это Java API, предназначенный для получения и отправки электронной почты с использованием протоколов SMTP, POP3 и IMAP.

JACC - Java Authorization Contract for Containers – это стандарт, который определяет контракты безопасности между модулями СП и политики авторизации. Эти контракты определяют способы установки, настройки и использования провайдеров авторизации в решениях доступа.

JCA - J2EE Connector Architecture – решение на базе технологии Java для соединения серверов приложений и корпоративных информационных систем в рамках решений интеграции корпоративных приложений.

JAF - JavaBeans Activation Framework - стандартное расширение для платформы Java, позволяющее воспользоваться стандартными услугами:

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

StAX - Streaming API for XML – интерфейс прикладного программирования для чтения и записи XML-файлов.

CDI - Context and Dependency Injection - Внедрение контекстов и зависимостей - помогают связать уровень веб-узлов и уровень транзакций платформы JEE. CDI - это набор услуг, которые, позволяют разработчикам использовать JavaBeans с JSF в веб-приложениях.

Microsoft.NET Framework

NET Framework - программная платформа, выпущенная компанией Microsoft в 2002 году. Основой платформы является общеязыковая среда исполнения Common Language Runtime (CLR), которая подходит для разных языков программирования. Функциональные возможности CLR доступны в любых языках программирования, использующих эту среду.

Считается, что платформа.NET Framework явилась ответом компании Microsoft на набравшую к тому времени большую популярность платформу Java компании Sun Microsystems (ныне принадлежит Oracle).

Хотя.NET является патентованной технологией корпорации Microsoft и официально рассчитана на работу под операционными системами семейства Microsoft Windows, существуют независимые проекты (прежде всего это Mono и Portable.NET), позволяющие запускать программы.NET на некоторых других операционных системах.

Архитектура.NET Программа для.NET Framework, написанная на любом поддерживаемом языке программирования, сначала переводится компилятором в единый для.NET промежуточный байт-код Common Intermediate Language (CIL) (ранее назывался Microsoft Intermediate Language, MSIL). В терминах.NET получается сборка, англ. assembly.

Затем код либо исполняется виртуальной машиной Common Language Runtime (CLR), либо транслируется утилитой NGen.exe в исполняемый код для конкретного целевого процессора. Использование виртуальной машины предпочтительно, так как избавляет разработчиков от необходимости заботиться об особенностях аппаратной части. В случае использования виртуальной машины CLR, встроенный в неё JIT-компилятор «на лету» (just in time) преобразует промежуточный байт-код в машинные коды нужного процессора. Современная технология динамической компиляции позволяет достигнуть высокого уровня быстродействия. Виртуальная машина CLR также сама заботится о базовой безопасности, управлении памятью и системе исключений, избавляя разработчика от части работы.

Microsoft начала разрабатывать.NET Framework в конце 1990-х под именем «Next Generation Windows Services» (NGWS). В 2000 году была выпущена первая бета-версия.NET 1.0.

–  –  –

Объектные классы.NET, доступные для всех поддерживаемых языков программирования, содержатся в библиотеке Framework Class Library (FCL). Ядро FCL называется Base Class Library (BCL).

Windows Forms – API, отвечающий за графический интерфейс пользователя.

ASP.NET(Active Server Pages) - технология создания вебприложений и веб-сервисов.

ADO.NET – технология, предоставляющая.NET-приложениям доступ к данным.

Windows Presentation Foundation (WPF) – система для построения клиентских приложений Windows с визуально привлекательными возможностями взаимодействия с пользователем. Разрабатываемые приложения могут быть автономными или запускаемыми в браузере.

Windows Communication Foundation (WCF) - программный фреймворк, используемый для обмена данными между приложениями. До выпуска в составе.NET Framework 3.0, был известен под кодовым именем Indigo. WCF позволяет создавать безопасные и надёжные транзакционные системы через упрощённую унифицированную программную модель межплатформенного взаимодействия. В WCF заложены принципы интероперабельности, которые позволяют организовывать работу с другими платформами.

Windows Workflow Foundation (WF) – технология для определения, выполнения и управления рабочими процессами (англ. workflow). (Рабочий процесс (поток) – 1. графическое представление процесса выполнения задачи и связанных с ним подпроцессов; 2. способ поступления информации к различным объектам, участвующим в процессе). WF ориентирована на визуальное программирование и использует декларативную модель программирования.

Windows CardSpace (WCS) – это способ идентификации пользователей при перемещении между ресурсами Интернета без необходимости повторного ввода имен и паролей. 15 февраля 2011 корпорация Майкрософт объявила об отмене Windows CardSpace 2.0 и о работе над замещающим ПО U-Prove.

Language Integrated Query (LINQ) - проект по добавлению синтаксиса языка запросов, напоминающего SQL (structured query language - «язык структурированных запросов»), в языки программирования платформы.NET.

ADO.NET Entity Framework (EF) - объектно-ориентированная технология доступа к данным. Предоставляет возможность взаимодействия с объектами как посредством LINQ (LINQ to Entities), так и с использованием Entity SQL.

Параллельный LINQ (PLINQ) – параллельная реализация LINQ to Objects.

PLINQ, реализующая полный набор стандартных операторов запроса LINQ в виде расширения для пространства имен T:System.Linq и имеющая дополнительные операторы для параллельных операций. PLINQ может значительно увеличить скорость запросов LINQ to Objects, эффективнее используя все доступные ядра на главном компьютере.

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

Modern UI Runtime – дизайнерский стиль, ориентированный на типографское оформление интерфейса пользователя.

Task-based Asynchronous Pattern (TAP) – основанная на задачах асинхронная модель – схема программирования, направленная на создание асинхронных потоков в выполнении программы и управление ими.

Одной из основных идей Microsoft.NET является совместимость программных частей, написанных на разных языках. Например, служба, написанная на C++ для Microsoft.NET, может обратиться к методу класса из библиотеки, написанной на Delphi. Каждая библиотека (сборка) в.NET имеет сведения о своей версии, что позволяет устранить возможные конфликты между разными версиями сборок.

Среды разработки, поддерживающие.NET:

Microsoft Visual Studio (C#, Visual Basic.NET, Managed C++, F#)

–  –  –

Приложения.NET также можно разрабатывать в текстовом редакторе, просто вызывая компилятор из командной строки.

Mono Mono - проект по созданию полноценного воплощения системы.NET Framework на базе свободного программного обеспечения.

Основной разработчик проекта Mono - компания Xamarin (ранее Novell). После заключения Microsoft договорённости с Novell, платформа Mono была официально признана реализацией.NET на Unix-подобных операционных системах: Linux, Mac OS X и других. (Хотя Mono успешно работает и под Microsoft Windows). Однако договорённость касается только Novell и клиентов Novell; также технологии ASP.NET, ADO.NET и Windows Forms не были стандартизированы ECMA/ISO, и использование их в Mono находится под угрозой юридических претензий со стороны Microsoft, поэтому Mono предоставляет реализацию ASP.NET, ADO.NET и Windows.Forms, но в

Похожие работы:

«ГЛАВА VI КОСМЕТИЧЕСКИЕ СРЕДСТВА, АРОМАТИЧЕСКИЕ ВЕЩЕСТВА И БЛАГОВОННЫЕ КУРЕНИЯ Косметические средства Косметика так же стара, как человеческое тщеславие. В Египте употребление косметических средств может быть прослежено почти от того самого периода, от ко...»

«2013 – № 32 Судовые энергетические установки 185 УДК 656.61.052.484 Репетей В.Д., ОНМА СОВЕРШЕНСТВОВАНИЕ ОРГАНИЗАЦИИ УПРАВЛЕНИЯ ОПЕРАЦИЯМИ SAR Постановка задачи в общем виде. Конечной целью совершенствования управления системой является оптимизация, которая предполагает наличие целевой функции управления f(x) ограничений по её...»

«OCR: Библиотека святоотеческой литературы http://orthlib.ru (с. 299) Мёсzца тогHже въ }i-й дeнь. С™aгw ґпcла и3 є3ђлjста луки2. И# прпdбнагw їHсифа волоцкaгw. Слyжба є3гw2 пи1сана септeмвріа, f7 днS. На вечeрни п...»

«РЕКОМЕНДАЦИИ КЛАССНЫМ РУКОВОДИТЕЛЯМ Формы работы по преодолению вредных привычек обучающихся Для эффективности внеклассной работы в этом направлении можно и нужно использовать следующие формы работы: просмотр видеофильмов с последующим обсуждением, просмотр кинофильмов, которые...» Статья посвящается досудебному порядку реализации предусмотренных законом мер защиты патентных прав в Российской Федерации. Ключевые слова: административный, защита...»

), некую параллель можно провести с конфигурированием способа запуска PHP-интерпретатора и его взаимодействия с выбранным web-сервером.

Прежде всего следует помнить, что существует несколько режимов запуска интерпретатора PHP – CGI, FastCGI или модуль к web-серверу. У каждого из этих режимов есть свои достоинства и недостатки, которые по-разному будут проявлять себя в зависимости от типовых условий эксплуатации системы и нагрузки на нее. Запуск в режиме CGI является самым медленным и иногда используется на разделяемом хостинге. Наиболее распространенным можно считать запуск PHP в качестве модуля к web-серверу. Именно такой режим обычно предпочитают новички и он вполне удобен для любых низконагруженных систем. Соответствующие модули существуют для разных web-серверов: Apache Web Server (mod_php), Microsoft IIS (до версии PHP 5.3).

Существует много попыток сравнения скорости и стабильности работы PHP-решений для разных конфигураций ("mod_php vs FastCGI" или "mod_php vs PHP-FPM" и т.д.). Сами разработчики Joomla/VirtueMart и Magento считают, что при использовании FastCGI достигаемые показатели производительности выше. Вместе с тем, при модульном запуске как правило уменьшается вероятность сбоев (ошибок обработки кода), а для тяжелых решений показатели производительности в большей степени зависят от применения различных техник кэширования php-кода. Поэтому для e-commerce систем, которые строятся на базе сложных и тяжеловесных библиотек, все-таки предпочтительнее использование модульного режима (mod_php для Apache HTTP Server). К таким «тяжеловесам» следует, в первую очередь, отнести любые решения на базе 1С-Битрикс: Управление сайтом . Использование FastCGI – обычно речь идет о менеджере php-fpm (FastCGI Process Manager) в паре с web-сервером Nginx или IIS FastCGI совместно с web-сервером Microsoft IIS – позволяет в ряде случаев действительно значительно повысить нагрузочную способность систем на платформах Magento и VirtueMart , а также является единственно возможным и для 1С-Битрикс: Управление сайтом при развертывании под IIS.

Может показаться, что FastCGI дает нам дополнительнительную гибкость, позволяя вообще выносить PHP-демон на другую машину, отделяя его от HTTP-сервера. Но аналогичная гибкость достигается и за счет выделения на фронте отдельного proxy-сервера, который маршрутизирует http-запросы и имеет свой механизм кэширования. Например, для кластерных конфигураций 1С-Битрикс: Управление сайтом в качестве proxy наилучшим образом подходит Nginx-сервер с активированным кэшированием.

Все сервера приложений, которые востребованы в платформах enterprise-класса ( , Oracle Commerce , SAP hybris), – это разнообразные J2EE-сервера, предназначенные для запуска апплетов (скриптов) на языке Java. Именно технологии Java лежат в основе всех трех рассматриваемых e-commerce платформ. Но у каждого из трех «китов» реализуется несколько различный подход к поддержке тех или иных серверов приложений. Так IBM предпочитает продвигать исключительно собственную технологию Websphere. SAP не имеет собственного продукта и ориентируется на продукты VMware. А Oracle поддерживает целый набор решений, как своих, так и сторонних. Итак, для названных e-commerce платформ возможно использование следующих серверов приложений.

• : IBM WebSphere Application Server;
• Oracle Commerce : Oracle Weblogic, IBM WebSphere Application Server, JBoss EAP;
• SAP hybris : VMware vFabric tc Server, Apache Tomcat.

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

Впрочем, если проводить детальный анализ характеристик разных J2EE-серверов, то окажется, что наиболее мощный и одновременно удобный продукт – это Oracle Weblogic Server. Он поддерживает очень богатый набор технологий, таких как Coherence, Oracle Traffic Director, InfiniBand и др. Обычно при сравнении Oracle Weblogic, например, с таким сервером как JBoss EAP много внимания уделяется стоимости лицензирования. Но для enterprise-систем разумно анализировать совокупную стоимость владения (TCO) на относительно протяженном интервале времени, а не разовую стоимость лицензирования. Кроме того, лицензионная политика вендоров, вообще говоря, может подразумевать включение необходимых лицензий на сервера приложений «в нагрузку» к приобретаемым лицензиям на e-commerce платформу. В любом случае, представляется достаточно примитивным подход, который не учитывает всех указанных факторов. Возвращаясь к сравнению TCO, можно заметить, что в настоящее время лидерство, похоже, следует отдать продукту VMware vFabric tc Server, который опережает другие решения за счет более эффективного использования процессора и памяти, а также благодаря очень гибким возможностям виртуализации на платформе VMware. Оптимальные же показатели TCO для продуктов Oracle можно получить при использовании комбинированного решения Exalogic, которое включает не только софт, но и специализированное оборудование.

В отношении IBM WebSphere Application Server существует проблема слабой документированности продукта и значительное «урезание» базового функционала, который затем нужно устанавливать отдельно в составе разнообразных дополнительных сервисов (продуктов). Вместе с тем, полная совокупность технологий от IBM также позволяет строить очень производительные системы с кластеризацией, резервированием, средствами мониторинга. Более того, некоторые функциональные возможности IBM WebSphere в сравнении с конкурирующими платформами совершенно уникальны и при разработке приложений не редко позволяют рассматривать эту платформу в качестве несомненного лидера. Но используя готовые e-commerce платформы, мы вынужденно ограничиваем себя и не используем все богатство архитектурных «изысков», доступных в том или ином окружении. Так что выбор конкретной технологии для сервера приложений в какой-то степени становится делом вкуса и пристрастий разработчиков и внедренцев конкретной e-commerce системы.

Под клиент-серверным приложением мы будем понимать информационную систему, основанную на использовании серверов баз данных (см. длинное замечание в конце раздела 2.1). Общее представление информационной системы в архитектуре "клиент-сервер" показано на рисунке 2.3.

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

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

(Здесь опять проявляются недостатки в терминологии. Обычно, когда компания объявляет о выпуске очередного сервера баз данных, то неявно понимается, что имеется и клиентская составляющая этого продукта. Сочетание "клиентская часть сервера баз данных" кажется несколько странным, но нам придется пользоваться именно этим термином.)

Рис. 2.3. Общее представление информационной системы в архитектуре "клиент-сервер"

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

Наконец, клиентская часть сервера баз данных, используя средства сетевого доступа, обращается к серверу баз данных, передавая ему текст оператора языка SQL.

Здесь необходимо сделать еще два замечания.

Обычно компании, производящие развитые серверы баз данных, стремятся к тому, чтобы обеспечить возможность использования своих продуктов не только в стандартных на сегодняшний день TCP/IP-ориентированных сетях, но в сетях, основанных на других протоколах (например, SNA или IPX/SPX). Поэтому при организации сетевых взаимодействий между клиентской и серверной частями СУБД часто используются не стандартные средства высокого уровня (например, механизмы программных гнезд или вызовов удаленных процедур), а собственные функционально подобные средства, менее зависящие от особенностей сетевых транспортных протоколов.

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

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

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

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

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

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

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

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

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

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

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

Рис. 2.4. "Тонкий" клиент и "толстый" сервер в клиент-серверной архитектуре

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

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

Рис. 2.5. "Потолстевший" клиент и "толстый" сервер в клиент-серверной архитектуре с поддержкой локального кэша на стороне клиентов

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

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

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