13. Процессы. Серверы

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

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

Клиент всегда посылает запросы в конечную точку (endpoint), также именуемую портом (port), той машины, на которой работает сервер. Каждый сервер просматривает указанную ему конечную точку. Эти конечные точки назначены организацией назначения номеров Интернета (Internet Assigned Numbers Authority, I ANA) и документированы. Имея назначенные конечные точки, клиенту достаточно знать сетевой адрес той машины, на которой запущена служба.

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

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

Еще один момент, который следует принимать во внимание при создании сервера, — когда и как сервер может быть прерван? Существует несколько способов сделать это. Один из подходов — пользователь немедленно закрывает клиентское приложение (что автоматически вызывает разрыв соединения с сервером), тут же перезапускает его и продолжает работу. Сервер, естественно, разрывает старое соединение, полагая, что клиент прервал работу. Более правильный способ вызвать прерывание связи — разрабатывать клиент и сервер так, чтобы они могли пересылать друг другу сигнал конца связи (out-of-band),

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

Сервер без фиксации состояния (stateless sewer) не сохраняет информацию о состоянии своих клиентов и может менять свое собственное состояние, не информируя об этом своих клиентов. Web-сервер, например, это сервер без фиксации состояния. Сервер с фиксацией состояния (stateful server)

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

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

Серверы объектов

Сервер объектов (object sewer) — это сервер, ориентированный на поддержку распределенных объектов. Важная разница между стандартным сервером объектов и другими (более традиционными) серверами состоит в том, что сам по себе сервер объектов не предоставляет конкретной службы. Конкретные службы реализуются объектами, расположенными на сервере. Сервер предоставляет только средства обращения к локальным объектам на основе запросов от удаленных клиентов. Таким образом, можно относительно легко изменить набор служб, просто добавляя или удаляя объекты. Сервер объектов, соответственно, выступает как место для хранения объектов. Объект состоит из двух частей: данных, отражающих его состояние, и кода, образующего реализацию его методов.

Альтернативы обращения к объектам

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

Более правильный подход со стороны сервера поддерживать различные правила обработки объектов.

Адаптер объектов

Правила обращения к объекту обычно называют политикой активизации

(activation policies), чтобы подчеркнуть тот факт, что во многих случаях объект, перед тем как к нему можно будет обратиться, должен быть перемещен в адресное пространство сервера (то есть активизирован).Нам нужен механизм группирования объектов в соответствии с политикой активизации каждого из них. Этот механизм называют адаптером объектов (objectadapter), или упаковщиком объектов (object wrapper), но чаще всего его существование скрыто в наборе средств построения сервера объектов. Адаптер объектов контролирует один или несколько объектов. Поскольку сервер должен одновременно поддерживать объекты с различной политикой активизации, на одном сервере может одновременно работать несколько адаптеров объектов. Единственное, что важно для адаптера объектов – это возможность извлечь ссылку на объект из запроса и передать запрос объекту в соответствии с его политикой активизации.