Inf_comp_sys

13.3Альтернативные архитектурные схемы расслоения системы

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

Прежде всего, рассмотрим так называемую модель Брауна [1]. Модель охватывает пять слоев: представление, контроллер/медиатор, домен (предметная область, бизнес-логика), отображение данных и источник данных. Два дополнительных слоя, по существу, выполняют посреднические функции между базовыми слоями: контроллер/медиатор соединяет слои представления и домена, а слой отображения данных служит связующим звеном между предметной областью и источником данных. Эти промежуточные слои полезны при применении таких типовых решений, как, контроллер приложения (посредник между представлением и бизнес логикой), и преобразователь данных (прослойка между источником данных и доменом). Мартин Фаулер [7] предлагает их рассматривать как факультативное проектное решение: если какой-либо из трех базовых слоев переходит разумную грань сложности, модель можно пополнить дополнительным слоем, принимающим на себя избыток функций.

Хорошая схема расслоения кода приложений на платформе J2EE реализована в виде набора типовых решений Core J2EE [10]. Здесь различаются следующие слои: клиент, представление, бизнес, интеграция и ресурсы. Для слоев бизнеса и интеграции существуют прямые аналоги в трехуровневой модели. Слой ресурсов представляет внешние службы, с которыми соединен слой интеграции. Но основное отличие связано с расщеплением слоя представления на две части между клиентом (слой клиента) и сервером (собственно слой представления). Это полезный подход, но он не всегда отвечает реальному положению вещей.

В архитектуре Microsoft DNA [12] различают три слоя — представление, бизнес и доступ к данным, которые довольно точно отвечают уже

101

рассмотренным трем слоям. Наибольшее отличие состоит в способе передачи информации от слоя доступа к данным. В Microsoft DNA все слои имеют дело с множествами записей, возвращаемыми SQL-запросами, которые инициировались кодом слоя доступа к данным. Отсюда следует, что слои бизнеса и представления непосредственно "осведомлены" о существовании базы данных. Это можно объяснить следующим образом: множество записей DNA действует как объект переноса данных между слоями. Слой бизнеса способен модифицировать множества записей на пути их следования к слою представления и даже создавать собственные множества. Хотя подобная форма коммуникаций довольно громоздка, она обладает тем немаловажным преимуществом, что позволяет слою представления пользоваться интерфейсными элементами управления, содержащими актуальную информацию, в том числе и измененную кодом слоя бизнеса. Слой домена в этом случае структурируется в форме модулей таблицы, а источник данных приобретает вид шлюзов таблицы данных [7].

Схема Маринеску [13] содержит пять слоев. Слой представления расщеплен на два слоя, отображающих структуру контроллера приложения. Домен также подвергся расщеплению: на основе модели предметной области сконструирован слой служб, что соответствует обычной практике деления бизнес логики на две части. Это общий подход, подкрепленный ограничениями модели EJB как модели предметной области [7]. Идея вычленения слоя служб из слоя предметной области основана на подходе, предполагающем возможность «отмежевания логики процесса от "чистой" бизнес логики». Уровень служб обычно охватывает логику, которая относится к конкретному варианту использования системы или обеспечивает взаимодействие с другими инфраструктурами (например, с помощью механизма сообщений). Стоит ли иметь отдельные слои служб и предметной области — это вопрос реализации конкретного проекта и подлежит детальному обсуждению.

Нильссоном предложена самая сложная схема расслоения программной системы [15]. Он предусматривает активное использование хранимых процедур и поощряет размещение в них фрагментов бизнес логики для повышения производительности приложения. Однако, возможность вынесения бизнес логики в хранимые модули чревата усложнением процедур сопровождения кода. С точки же зрения повышения производительности такой подход совершенно оправдан и полезен. Слои хранимых процедур Нильссона содержат как источники данных, так и бизнес-логику. Как и Маринеску, для описания бизнес логики Нильссон использует отдельные слои приложения и домена. Он предлагает возможность отказа от слоя домена в малых системах в пользу более простых типовых решений моделирования предметной области.

102

Глава 14. Типовые архитектурные решения

14.1Типовые решения уровня представления

14.1.1 Контроллер страниц

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

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

Контроллер страниц может быть реализован в виде сценария (сценария CGI, сервлета и т.п.) или страницы сервера (ASP, PHP, JSP и т.п.). При необходимости одни адреса URL можно обрабатывать с помощью страниц сервера, а другие — с помощью сценариев. Те адреса URL, у которых нет или почти нет логики контроллера, хорошо обрабатывать с помощью страниц сервера, потому что последние представляют собой простой механизм, удобный для понимания и внесения изменений. Все остальные адреса, для обработки которых необходима более сложная логика, требуют применения сценариев.

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

14.1.2 Контроллер запросов

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

Контроллер запросов обрабатывает все запросы, поступающие к Webсайту, и обычно состоит из двух частей: Web-обработчика и иерархии команд. Web-обработчик — это объект, который выполняет фактическое получение POSTили GET-запросов, поступивших на Web-сервер. Он извлекает необходимую информацию из адреса URL и входных данных запроса, после

103

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

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

Наиболее часто упоминаемым преимуществом контроллера запросов является возможность реализации общего кода, который дублируется в многочисленных контроллерах страниц. Контроллер запросов только один, что позволяет легко изменять его поведение во время выполнения с помощью многочисленных декораторов [3]. Декораторы могут применяться для проведения аутентификации, выбора кодировки, обеспечения поддержки интернационализации и т.п. Более того, их можно добавлять не только с помощью файла настроек, но и прямо во время работы сервера с использованием подхода под названием перехватывающий фильтр приводится в [10].

14.1.3 Представление по шаблону

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

Одной из наиболее популярных форм представления по шаблону является страница сервера (serverpage) — ASP, JSP или PHP. Страницы сервера позволяют внедрять в страницу элементы программной логики, называемые скриптлетами, но это усложняет их понимание и сопровождение. Наиболее очевидный недостаток внедрения в страницу сервера множества скриптлетов состоит в том, что ее могут редактировать исключительно программисты. Данная проблема особенно критична, если проектированием страницы занимаются графические дизайнеры. Однако самые существенные недостатки скриптлетов связаны с тем, что страница — далеко не самый подходящий модуль для программы. Даже при использовании объектно-ориентированных языков программирования внедрение кода в текст страницы лишает возможности применения многих средств структурирования, необходимых для

104

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

14.1.4 Представление с преобразованием

Представление с преобразованием – это представление, которое поочередно обрабатывает элементы данных домена и преобразует их в код HTML. Данные, получаемые по запросам к слоям домена и источника данных, не имеют нужного форматирования для создания Web-страницы. Визуализацией полученных данных в элементы Web-страницы занимается объект, исполняющий роль представления в системе модель-представление- контроллер. В типовом решении представление с преобразованием процесс визуализации данных рассматривается как преобразование, на вход которого подаются данные из модели, а на выходе принимается код HTML. Программа преобразования может быть написано на любом языке. Тем не менее, на данный момент наиболее популярным языком для написания представлений с преобразованием является XSLT. Для применения преобразований XSLT данные домена должны находиться в формате XML. Этого проще достичь, когда логика домена сразу же возвращает данные в формате XML или любом другом, который может быть легко преобразован в XML, например объекты .NET. Данные домена в формате XML передаются процессору XSLT. В настоящее время на рынке программного обеспечения доступно большое количество коммерческих процессоров XSLT. Логика преобразования содержится в таблице стилей XSLT, которая также передается процессору. Последний применяет таблицу стилей к входным данным XML и преобразует их в код HTML, который сразу же может быть помещен в HTTP-запрос.

Одним из преимуществ XSLT является хорошая переносимость практически на все Web-платформы. Одну и ту же таблицу стилей XSLT можно применять для преобразования данных XML, созданных на основе объектов J2EE или .NET, что позволяет применять общие HTML-представления для данных, полученных из различных источников.

14.1.5 Контроллер приложения

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

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

105

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

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

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

14.2Типовые решения уровня бизнес логики

14.2.1 Сценарий транзакции

Сценарий транзакций – это способ организации бизнес логики по процедурам, каждая из которых обслуживает один запрос, инициируемый споем представления. Многие бизнес-приложения могут восприниматься как последовательности транзакций. Одна транзакция способна модифицировать данные, другая — воспринимать их в структурированном виде и т.д. Каждый акт взаимодействия клиента с сервером описывается определенным фрагментом логики. В одних случаях задача оказывается настолько же простой, как отображение части содержимого базы данных. В других могут предусматриваться многочисленные вычислительные и контрольные операции.

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

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

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

Где расположить сценарий транзакции, зависит от организации слоев системы. Этим местом может быть страница сервера, сценарий CGI или объект

106

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

Существует два способа разнесения кода сценариев транзакции по классам. Наиболее общий подход, прямолинейный и удобный во многих ситуациях — использование одного класса для реализации нескольких сценариев транзакции. Второй, следующий схеме типового решения команда [3], связан с разработкой собственного класса для каждого сценария транзакции: определяется тип, базовый по отношению ко всем командам, в котором предусматривается некий метод выполнения, удовлетворяющий логике сценария транзакции. Преимущество такого подхода — возможность манипулировать экземплярами сценариев как объектами в период выполнения.

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

14.2.2 Модель предметной области

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

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

107

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

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

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

14.2.3 Модуль таблицы

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

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

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

108

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

14.2.4 Слой служб

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

То, какие операции должны быть размещены в слое служб, определяется нуждами клиентов слоя служб, первой (и наиболее важной) из которых является пользовательский интерфейс. Именно он предназначен для поддержки вариантов использования приложения, поэтому в качестве отправной точки для определения набора операций слоя служб должны рассматриваться модель вариантов использования и пользовательский интерфейс приложения. При этом большинство вариантов использования корпоративных приложений составляют операции CRUD (create, read, update, delete) - «создать», «считать», «обновить», «удалить» над объектами домена. На практике варианты такого использования практически всегда полностью соответствуют операциям слоя служб.

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

Преимуществом использования слоя служб является возможность определения набора общих операций, доступных для применения многими

109

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

14.3Типовые решения уровня источника данных

14.3.1 Шлюз таблицы данных

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

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

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

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

110