Inf_comp_sys

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

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

11.4.5 Данные с отдельной схемой

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

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

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

11.4.6 Несовместимые данные

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

Обычно это покупные или уже существующие системы, являющиеся несовместимыми в результате отсутствия централизованного планирования.

11.5Синхронные и несинхронные данные

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

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

При цикличном (не мгновенном) обновлении копий данных говорят об

актуальности данных на заранее известных конкретный момент времени.

91

11.6Основания для многократного распределения копий данных

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

Время реагирования. Доступ к данным, расположенным тут же, а не на расстоянии, может значительно сократить время реагирования.

Доступность. Обращение к локально размещенным данным или к их копиям может значительно повысить доступность данных.

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

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

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

11.7Матрицы распределения

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

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

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

92

Раздел III. Архитектура программных приложений

Глава 12. Концепция расслоения системы

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

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

93

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

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

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

94

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

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

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

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

95

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

96

Глава 13. Многоуровневые модели программных приложений

Концепция слоев, уровней или ярусов является основополагающей в многоуровневой организации программного обеспечения не только корпоративных информационных систем. В архитектурах компьютерных систем различают слои кода на языке программирования, функций операционной системы, драйверов устройств, наборов инструкций центрального процессора и внутренней логики микросхем. В среде сетевого взаимодействия и реализации сетевых протоколов можно привести примеры функционирования прикладной службы FTP поверх транспортного протокола TCP, который, в свою очередь, функционирует поверх протокола IP, расположенного над протоколом Ethernet. При этом подразумевается относительная непроницаемость слоев. Слой более высокого уровня пользуется службами, предоставляемыми нижележащим слоем, но тот не знает о наличии соседнего вышележащего слоя. Каждый промежуточный слой экранирует нижний слой от верхнего: например, слой 4 пользуется услугами слоя 3, который обращается к слою 2, но слой 4 не знает о существовании слоя 2. В этом есть определенные преимущества. Так каждый слой можно рассматривать как единое целое, не особенно заботясь о наличии других слоев (для создания службы FTP необходимо знать протокол TCP, но не тонкости Ethernet). Можно выбирать альтернативную реализацию каждого слоя, например: слоя 4, не затрагивая при этом реализации слоев 1 и 2. Нижележащий слой может служить основой для нескольких вышележащих слоев (IP, как основа для TCP и UDP). Наряду с этим можно отметить и ряд недостатков. Так модификация одного слоя, как правило, связана с необходимостью внесения каскадных изменений в остальные слои. Классическим примером может служить добавление поля в таблицу базы данных, которое подлежит воспроизведению в графическом интерфейсе и должно найти соответствующее отображение в каждом промежуточном слое. Избыточное преобразование представления моделируемых сущностей при переходе между слоями ради инкапсуляции нижележащих функций снижает производительность системы, хотя и предоставляет определенные преимущества при проектировании. При этом наиболее трудной задачей является определение содержимого и границ ответственности каждого слоя.

13.1Трехуровневая модель расслоения системы

К основным архитектурным слоям многоуровневых приложений можно отнести следующие три слоя: представление, домен (предметная область, бизнес-логика) и источник данных [7].

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

97

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

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

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

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

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

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

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

98

13.2Распределение слоев по функциональному принципу

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

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

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

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

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

99

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

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

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

Если в рамках клиента все же необходимо выполнять какие-либо функции логики предметной области, то, прежде всего, уместно рассмотреть возможность поручения клиенту всех таких функций. Подобный вариант очень похож на выбор интерфейса толстого клиента. Запуск Web-сервера на клиентской машине ненамного повысит быстроту реагирования приложения, хотя даст возможность использовать его в локальном режиме. Где бы ни находился код бизнес логики, его следует сохранять в отдельных модулях, не связанных со слоем представления, используя одно из типовых решений— сценарий транзакции или модель предметной области [7]. Передача клиенту всего кода бизнес логики сопровождается усложнением процедур обновления системы.

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

100