Файл: Понятие прикладных протоколов и серверы приложений (Понятие серверов приложений).pdf

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

Рисунок 1 - Модель "сервер приложений"

Первый уровень, интерфейсный, как правило, графический (GUI).

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

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

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

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

Сервер приложений создается на основе удаленного модуля данных, который служит для размещения компонентов, а также для обеспечения взаимодействия с сервером и клиентами. Для создания различных серверов приложений предназначены следующие разновидности удаленных модулей данных^[4]:

· Remote Data Module – для серверов DCOM, TCP/IP;

· Transactional Data Module – для сервера MTS;

· WebSnap Data Module – для сервера Web;

· SOAP Server Data Module – для серверов SOAP.

Удаленные модули данных расположены на страницах Multitier, WebSnap и WebServices Хранилища объектов. Хранилище объектов – средство Delphi, которое используется для хранения объектов (шаблоны приложений, форм, отчетов и т.д.), которые могут быть многократно использованы в качестве шаблонов для разработки приложений. Вставить в приложение новый объект можно, открыв командой File\New\Other (Файл\Новый\Другой) окно New Items (Новые элементы) для выбора нового объекта в хранилище.

В удаленном модуле данных размещаются те же компоненты, что и в простом модуле данных, например, для механизма доступа с помощью BDE такие компоненты, как Query, Database, Session, предназначенные для организации доступа к данным.

Рассмотрим создание простейшего сервера приложений – сервера DCOM, взаимодействие с которым основано на технологии DCOM. Для работы этого сервера необходимо, чтобы в системе была установлена программная поддержка функционирования распределенных СОМ-объектов, которая имеется в операционных системах Windows 98/NT/2000. Для Windows 95 ее нужно устанавливать отдельно. Поддержка распределенных СОМ-объектов устанавливается автоматически при инсталляции ряда программ Windows.

---

Добавление к проекту удаленного модуля данных выполняется выбором объекта Remote Data Module страницы Multitier Хранилища объектов. При добавлении модуля выводится диалоговое окно мастера Remote Data Module Wizard, в котором нужно задать параметры модуля (рис. 2).

Рисунок 2 - Добавление удаленного модуля данных

В поле редактирования CoClass Name вводится имя модуля данных. В списке Instancing (Создание экземпляров) выбирается способ запуска модуля:

· Internal – экземпляр модуля данных создается на сервере в случае, когда модуль данных является частью библиотеки DLL;

· Single Instance – для каждого клиента в его адресном пространстве создается один экземпляр удаленного модуля данных, и каждое клиентское соединение запускает этот свой экземпляр;

· Multiple Instance – один экземпляр приложения (процесс) представляет все удаленные модули данных, созданные для клиентов (по умолчанию); каждый удаленный модуль данных предназначен для одного клиентского соединения, но все они разделяют одно и то же адресное пространство.

В списке Threading Model (Потоковая модель) выбирается способ вызова интерфейса клиента, если модуль данных является частью библиотеки DLL:

· Single – библиотека получает запросы клиента по одному;

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

· Free – отдельный экземпляр модуля данных одновременно может отвечать на несколько запросов клиентов;

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

· Neutral – разные клиенты могут одновременно вызывать удаленный модуль данных из нескольких потоков, при этом модель СОМ следит за тем, чтобы не было конфликта вызовов (однако нужно иметь в виду возможный конфликт потоков: он отслеживается только в версии СОМ+, при отсутствии ее используется потоковая модель типа Apartment).

После нажатия кнопки ОК модуль данных с установленными параметрами добавляется к проекту. В приведенном на рис. 2 примере модулю присвоено имя ServerDCOM, а два других параметра оставлены без изменений.

На этапе проектирования внешний вид удаленного модуля не отличается от вида простого модуля данных. Как и в простом модуле, в удаленном модуле данных размещаются невизуальные компоненты, используемые для доступа к данным. Здесь могут быть наборы компонентов для механизмов доступа ADO, BDE, dbExpress и InterBase Express. К примеру, для технологии BDE чаще всего этими компонентами являются Query, Table, Database, Session, а также DataSetProvider. В самом простом случае достаточно разместить в модуле только набор данных. Например, разместим в удаленном модуле набор данных Query и зададим для него значения свойств DataBaseName и SQL так, чтобы включить в набор все поля всех записей таблицы Personnel. Указанным свойствам присвоим значения:

---

· свойству DataBaseName – значение BDPlace;

· свойству SQL – значение SELECT * FROM Personnel.db.

На этом создание простейшего сервера DCOM закончено. Перечислим еще раз действия, которые были при этом выполнены:

· к проекту добавлен удаленный модуль данных;

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

Созданное приложение сервера состоит из следующих частей:

· проект;

· главная форма приложения;

· удаленный модуль данных;

· модуль библиотеки типов.

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

Библиотека типов создается автоматически, а ее модуль сохраняется на диске при сохранении других файлов проекта. Библиотека занимает два файла:

Project.tlb и Project_TLB.pas, где Project – имя проекта.

После создания сервера DCOM его нужно зарегистрировать как сервер автоматизации. Регистрация сервера выполняется системой Windows автоматически при запуске приложения сервера.

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

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

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

Для реализации ограничений в сервере приложений при использовании технологии BDE можно использовать свойство Constraints типа TCheckConstraints наборов данных Table и Query. Тип TCheckConstraints представляет собой коллекцию (набор) отдельных ограничений типа TCheckConstraint, имеющих следующие свойства:

---

· CustomConstraint типа String – код SQL, описывающий ограничение;

· ErrorMessage типа String – текст, выдаваемый пользователю при нарушении данного ограничения;

· FromDictionary типа Boolean – признак, значение True которого указывает, что ограничение выбирается из словаря данных; по умолчанию свойство имеет значение False, и словарь данных не используется;

· ImportedConstraint типа String – код SQL, описывающий ограничение, которое импортировано из словаря данных.

Для задания ограничений нужно выделить набор данных, и в окне Инспектора объектов щелчком в области значения свойства Constraints открыть окно, показанное на рис. 1.3, справа. Центральную часть окна занимает список ограничений, применяемых к набору данных, имя которого выводится в заголовке окна (на рисунке – Query1). Добавление к списку нового ограничения выполняется командой Add контекстного меню, нажатием клавиши <Insert> или нажати­ем крайней левой кнопки на панели инструментов. Существующие ограничения можно удалять и перемещать в пределах списка, эти действия выполняются с помощью команд контекстного меню, нажатия клавиш или кнопок панели ин­струментов.

Сразу после добавления ограничение "пустое", и в списке выводится название его типа TCheckConstraint (на рис. 1.3 это третье ограничение). Для задания ограничения нужно его описать, например, присвоив значения свойствам CustomConstraint и ErrorMessage. После того как свойство CustomConstraint получит значение, оно будет выведено в списке ограничений. Свойства ограничения становятся доступными через Инспектор объектов после выбора ограничения в списке.

Рисунок 3 - Определение ограничений для набора данных Query1

В приведенном на рис. 3 примере для данных о сотрудниках организации (таблица Personnel) установлены ограничения на значения полей Name и Salary: поле имени не может быть пустым, а значение оклада должно быть положительным. При нарушении этих ограничений пользователю выдаются соответствующие сообщения, например, если не задано значение поля Name, то выдается сообщение "Не задано имя".

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

---

Свойства CustomConstraint, ConstraintErrorMessage и ImportedConstraint объектов типа TField позволяют задать ограничения для отдельных полей набора данных. Эти свойства аналогичны свойствам CustomConstraint, ErrorMessage и ImportedConstraint объекта типа TcheckConstraints.

2.2 Обзор серверов приложений

Мы хотим сделать небольшой обзор той части серверов приложений, которые заслуживают внимания хотя бы тем, что являются бесплатными и доступен их исходный код. Мы будем исходить из того, что ваша система сходна с нашей. У нас стоит Windows 7 64 бита, кроме того стоит JDK 1.7 и JDK 1.8, а переменная окружения JAVA_HOME ссылается на последний из них. В нашем случае это значит, что в JAVA_HOME прописан путь C:\Program Files\Java\jdk1.8.0_31.

Мы будем пытаться описывать каждое действие, которое делали на своей машине.

Для начала нужно отобрать сервера приложений для нашего обзора^[5].

1. Glassfish (не проприетарный, а тот, что от сообщества glassfish.java.net, но который поддерживается корпорацией Oracle до такой степени, что если нужен javaEE SDK с сайта Oracle, то тебе впиндюрят и этот сервер приложений, иначе никак)
2. (Red Hat) WildFly (бывший JBoss)
3. (Apache) Geronimo
4. (Apache) Tomcat (это лишь контейнер сервлетов, а не сервер приложений, но он является таким эталоном, на котором, если программа написана правильно, то она точно заработает. На других серверах программа может быть написана правильно с точки зрения JavaEE, но работать все равно будет не корректно или вообще не будет. Это я о Geronimo, о глюках которого можно говорить долго)

Итак, установка.

В плане установки все просто и для каждого из выбранных серверов установка – это просто распаковка архива. Мы, например, создали папку AppServers на рабочем столе, куда и стали всё распаковывать.

Настройка

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

Для Tomcat. Заходим в папку с распакованным tomcat, далее папка conf, файл server.xml. Находим в этом файле число 8080 (http порт по умолчанию) и меняем его на что захотим. Я поставил 9713.

Чтобы прописать себя как админа сервера нужно, находясь в этой же папке, открыть файл tomcat-users.xml. В нем перед закрывающим тегом </tomcat-users> прописать следующий тег:

<user username="egarmin" password="1" roles="manager-gui,manager-script,manager-status,manager-jmx"/>

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

---