Когда без распределения не обойтись

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

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

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

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

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

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

Сужение границ распределения

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

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

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

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

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