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

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

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

Рис. 1. Цепочка передачи данных в клиент-серверной архитектуре

Какими порциями и в каких случаях надо обновлять экран пользователя? Возможны самые разные варианты — от полного обновления при использовании статического HTML (страница с формой загружается в браузер, измененная форма отправляется на сервер) до передачи событий отдельным измененным объектам от клиентской стороны к серверу и обратно. Из-за того, что пользовательский интерфейс строится по несколько иным законам, чем бизнес-логика приложения, практически всегда необходимо связывать бизнес-объекты и элементы графического интерфейса пользователя. Это, как правило, требует написания некоторого дополнительного программного кода. Такая «связующая» логика может располагаться как на клиенте, так и на сервере, и тогда водораздел «клиент — сервер» проходит либо через изменение визуальных элементов управления (передаются события в GUI, как в терминальных клиентах), либо через изменение клиентских представлений объектов.

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

Рис. 2. Отображение объектной поверхности GUI в Baikonur/Taxxi

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

Двухзвенная клиент-серверная архитектура была настоящим бестселлером до WWW-эпохи. Затем появился браузер как тонкий клиент, которому прочили судьбу «убийцы» двухзвенного подхода, но пророчества эти оказались преждевременными. Данный подход породил ряд иллюзий, вызванных концептуальной красотой решения, однако Internet-приложения оказались более сложными в разработке, чем это казалось на первый взгляд, причем пользователи, как правило, расплачиваются неудобством сильно урезанного Web-интерфейса по сравнению с «классическим» графическим пользовательским интерфейсом настольных приложений. Для того чтобы построить равное по функциональным возможностям и удобству использования Web-приложение, надо обладать большим опытом, и требования к Web-программистам, как правило, значительно выше, чем требования к «обычным» прикладным программистам.

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

Taxxi: объектная поверхность

Сервер приложений Baikonur во многом предвосхищал ставшую популярной лишь годы спустя трехзвенную архитектуру. Дополненный компонентами быстрой разработки, интегрированными с очень распространенным и поныне инструментарием Delphi, сервер приложений Baikonur привлек внимание разработчиков своей концептуальной продуманностью и простотой создания полноценных приложений с Web-интерфейсом. Пройдя стадии клиентов на базе HTML и Java, технология Baikonur пришла к концепции «объектной поверхности» в сверхтонком Windows-клиенте Taxxi. Последний представляет собой, по сути, легкий (около 400 Кбайт) XML-браузер, который отрисовывает пользовательский интерфейс. На клиенте, помимо Taxxi, устанавливается также Baikonur-сервер (еще около 1 Мбайт), и в этом смысле сам клиент приобретает черты сервера, а само решение содержит все характерные черты распределенных приложений.

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

Парадигма объектной поверхности, по-видимому, оптимальна для распределенных систем со слабыми каналами: в ней минимизируется трафик взаимодействия клиента и сервера за счет того, что передаются только содержательные данные по отрисовке пользовательского интерфейса. Кроме того, проработанность решения с точки зрения сопряжения пользовательского интерфейса (Taxxi — лишь GUI-клиент, взаимодействующий с сервером) сокращает трудоемкость написания приложений в средах, подобных Delphi.

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

VisualDoc: объектное пространство

Если в Taxxi клиент и сервер взаимодействуют на уровне объектной поверхности GUI, то в технологии VisualDoc это взаимодействие происходит на уровне бизнес-объектов, которые расположены на сервере, но имеют клиентские представления.

VisualDoc — это не только сервер приложений, но и объектная СУБД, построенная поверх стандартной реляционной СУБД. Объекты принадлежат настраиваемой схеме данных: путем задания структуры классов и связей между ними создается каркас будущего приложения, который отражается в хранилище.

Чтобы понять суть подхода VisualDoc, рассмотрим простой пример — на клиенте имеется приложение, которое отражает на форме или в табличном представлении значения полей некоторых объектов из базы данных. Когда пользователь правит данные, изменяя через элементы пользовательского интерфейса поля объектов, создавая и удаляя объекты, это отражается на сервере приложений, а также в хранилище. Объекты на клиенте — это всего лишь представления объектов на сервере. При изменении объектов на сервере, помимо сохранения их в базе данных, происходит уведомление тех клиентов, которые загрузили клиентские представления этих объектов, т.е. включили их в свое рабочее объектное пространство. На события изменений клиентских объектов можно стандартным образом подключать обработчики, например, на JavaScript, в результате чего мы имеем распределенное приложение. На клиентской части идет связывание элементов графического пользовательского интерфейса и полей объектов; при этом изменения объектов передаются как от клиента к серверу, так и обратно.

Сервер VisualDoc предоставляет такие механизмы, как транзакции, кэширование, разграничение прав доступа, версионность объектов, при этом данные хранятся в нижележащей СУБД (Microsoft SQL Server или Oracle). Клиент и сервер общаются посредством специального протокола (можно выбрать либо бинарный, либо основанный на XML протокол), а клиентские объекты, в том числе и схема данных, доступны через COM-интерфейс.

Рис. 3. Отображение объектного пространства в VisualDoc

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

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

Avalon для Longhorn

В следующем поколении Windows, по-видимому, кардинальным образом изменится парадигма построения пользовательского интерфейса. Презентационная подсистема Longhorn с рабочим названием Avalon по своей архитектуре больше походит на клиентские Web-приложения: средой для GUI выступает браузер, элементы пользовательского интерфейса в рамках страниц разметки задаются на родственном XML языке XAML, а связывание их с логикой осуществляется подобно тому, как это делается в случае DHTML/JavaScript.

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

Какой вариант лучше?

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

Влад Жигалов (zhigalov@aha.ru) — аналитик компании «ЦентрИнвест Софт» (Москва).