Архитектура распределенных вычислений
Введение в распределенные вычисления
Ограничения двухзвенных приложений
Многозвенные приложения и Windows DNA
Требования к приложениям Windows DNA
В статьях цикла «Введение в базы данных» (КомпьютерПресс № 3-12’2000) мы обсуждали базы данных, приложения, их применяющие, а также технологии доступа к данным, средства проектирования данных и создания приложений. Как правило, при рассмотрении подобных приложений предполагается, что они созданы в традиционной, так называемой двухзвенной, архитектуре, то есть что приложение, применяющее базы данных, состоит из двух частей, одна из которых предоставляет услуги, связанные с хранением и обслуживанием данных (сервисы данных), а другая — предоставляет эти данные пользователю для редактирования или использования (презентационные сервисы).
Данный цикл статей посвящен многозвенным, или распределенным, приложениям. В настоящей статье мы рассмотрим основы организации распределенных вычислений и основные принципы архитектуры Windows DNA (Distributed interNet Applications), предназначенной для создания приложений для платформ Windows и .Net.
Введение в распределенные вычисления
Ограничения двухзвенных приложений
Начнем с того, что вспомним, что представляет собой «классическое» двухзвенное приложение, реализованное в архитектуре «клиент-сервер».
Как вы уже знаете (из первой части цикла «Введение в базы данных», подобные приложения состоят из двух частей (звеньев): сервера баз данных и клиентского приложения. Сервер баз данных предназначен для хранения данных, поддержки их ссылочной целостности, а также определенных пользователями бизнес-правил, реализованных в виде хранимых процедур, триггеров, серверных ограничений и иных объектов базы данных. Иными словами, в данном случае сервер баз данных предоставляет как сервисы данных, так и сервисы бизнес-правил.
Несмотря на свою многолетнюю популярность, этот подход имеет ряд ограничений, главным из которых является то, что двухзвенное приложение не способно контролировать свои критические ресурсы, то есть ресурсы, жизненно необходимые для надежной работы приложения, — соединения с базами данных и транзакции.
В двухзвенной архитектуре критические ресурсы доступны клиентским приложениям, которые при этом могут пользоваться ими сколь угодно долго. Именно поэтому в случае непредсказуемого поведения клиентского приложения эти ресурсы практически невозможно защитить. Типичным примером такого непредсказуемого поведения является выполнение одним из клиентских приложений запроса, нуждающегося в ресурсах всего сервера баз данных на длительное время, что практически исключает работу с данными для остальных клиентских приложений до тех пор, пока этот запрос не выполнится. Возможность подобного «захвата ресурсов» позволяет любому клиентскому приложению, случайно или намеренно, вывести всю информационную систему из-под контроля.
Другие проблемы не столь существенны, но их также стоит принять во внимание. Как уже отмечалось выше, в обычных клиент-серверных приложениях бизнес-правила могут быть реализованы в объектах базы данных — триггерах, хранимых процедурах, серверных ограничениях. Отладка кода этих объектов в принципе осуществима, но она далеко не так удобна, как отладка кода клиентских приложений. В большинстве случаев реализация бизнес-правил в виде серверных объектов сходна с созданием приложений на старых языках программирования в устаревших операционных системах без использования среды разработки, что отнюдь не способствует повышению скорости создания и тестирования кода.
Нередко клиентское приложение может содержать код, предназначенный для проверки корректности вводимых данных и их обработки. В этом случае необходимо включать этот код во все клиентские приложения, которые могут обращаться к этой базе данных, и предотвращать доступ к ней из любых других приложений. Приложения, доступ из которых к базе данных разрешен, иногда определяют термином trusted applications.
Ряд указанных проблем можно решить с помощью применения многозвенных приложений. В следующем разделе мы расскажем об основных принципах архитектуры Windows DNA и о способах решения с ее помощью описанных выше проблемы.
 |
|
Многозвенные приложения и Windows DNA
Windows DNA — это архитектура трехзвенных Windows-приложений, состоящих из следующих логических звеньев:
- презентационные сервисы, или «тонкие» клиенты;
- сервисы бизнес-логики, или сервисы промежуточного слоя — middle tier;
- сервисы данных — как правило, сервер баз данных и технологии доступа к данным.
Рассмотрим наиболее важные особенности каждого из звеньев более подробно.
|
|
Презентационные сервисы
Презентационные сервисы предназначены для взаимодействия с пользователем и передачи данных, введенных пользователем, к сервисам бизнес-логики для их обработки, получения от них результатов этой обработки и, наконец, для предоставления их пользователю. Презентационные сервисы могут быть реализованы в Web-браузере (HTML-приложения) или в виде обычных Windows-приложений.
Главными элементами презентационных сервисов в Windows DNA являются HTML и Dynamic HTML, компоненты ActiveX, функции Win32 API.
Презентационные сервисы могут быть интерактивными и неинтерактивными:
- интерактивные презентационные сервисы реагируют на пользовательский ввод непосредственно после него. Подобные сервисы могут быть реализованы в виде Windows-приложений или в виде кода на одном из скриптовых языков (JavaScript, VBScript), интерпретируемого Web-браузером;
- неинтерактивные презентационные сервисы реагируют на пользовательский ввод только после отправки запроса, содержащего введенные пользователем данные, к сервисам бизнес-логики и получения от них ответа.
В случае если клиентское приложение способно получать от сервисов промежуточного слоя бизнес-объекты, проверяющие корректность введенных данных, презентационные сервисы, реализованные в этом приложении, как правило, интерактивны. Обычно такое приложение способно проверять корректность введенных данных не только на уровне целой записи базы данных, но и на уровне отдельного поля такой записи.
|
|
Бизнес-сервисы
Сервисы бизнес-логики предназначены для получения введенных пользователем данных от презентационных сервисов, для взаимодействия с сервисами данных в целях выполнения бизнес-операций (например, обработки заказов или расчета бухгалтерского баланса) и для возврата результатов этих операций презентационным сервисам.
Обычно сервисы бизнес-логики реализуются в виде бизнес-объектов, создаваемых внутри приложений или библиотек. Некоторые из бизнес-объектов могут обращаться к сервисам данных, используя универсальный механизм доступа к данным Microsoft (Microsoft Universal Data Access), в частности механизмы OLE DB и ADO («Введение в базы данных. Часть 5». КомпьютерПресс № 8’2000).
Бизнес-сервисы реализуются с помощью следующих ключевых технологий:
- Internet Information Services (IIS) — управляющие Web-приложениями и содержащих в своем адресном пространстве бизнес-объекты;
- COM/COM+ Services — позволяющие создавать приложения с компонентами, выполняющимися асинхронно, а также приложения, затрагивающие разные компоненты и базы данных.
В Microsoft Windows NT 4.0 эта функциональность была реализована средствами Microsoft Message Queue Services (MSMQ) и Microsoft Transaction Server (MTS), а функциональность Internet Information Services (IIS) — в Internet Information Server. Все три эти продукта являются частью Windows NT 4 Option Pack, доступного на Web-сервере компании Microsoft по адресу http://www.microsoft.com/.
|
|
Сервисы данных
Сервисы данных предназначены для хранения и извлечения данных, а также поддержки их целостности — Они выполняют задачи, типичные для серверов баз данных. В Windows DNA ключевыми элементами для построения сервисов данных являются:
- Microsoft SQL Server — серверная СУБД для хранения реляционных и нереляционных данных;
- Microsoft Universal Data Access — механизм доступа к этим данным;
- Microsoft Exchange Server — набор сервисов для обеспечения документооборота внутри предприятия.
Сервисы данных могут быть реализованы не только в виде серверов баз данных, но и в виде файловой системы, данных электронной почты и т.д. Microsoft Universal Data Access позволяет обеспечить доступ к таким данным с помощью соответствующих OLE DB-провайдеров.
|
|
Коротко о бизнес-объектах
В отличие от обычных приложений в архитектуре «клиент-сервер», в приложениях с архитектурой Windows DNA клиенты не имеют непосредственного доступа к критическим ресурсам, таким как соединения с базами данных. Вместо этого клиенты посылают запросы к специально предназначенным для этой цели бизнес-объектам (trusted objects). Такие объекты могут выполнять запрошенные клиентом бизнес-операции, и именно эти объекты, а не клиенты, имеют доступ к критическим ресурсам. Например, если такой объект должен обрабатывать заказы, то он должен найти заказанный товар в базе данных склада, отметить выбранную позицию как заказанную, вычислить сумму платежа и добавить запись к списку выписанных счетов.
Бизнес-объекты создаются так, что способ использования ими критических ресурсов заранее определен и предсказуем. Следовательно, приложение Windows DNA может контролировать эти ресурсы на протяжении всего времени своего функционирования, что обеспечивает стабильность его работы. Следует отметить, что до того как бизнес-объект начнет выполнять любую бизнес-операцию, он должен идентифицировать клиента, пославшего запрос, проверить, имеются ли у этого клиента права на запрос подобной операции, а также проверить синтаксис запроса и данные, полученные от клиента.
С целью снижения возможности отправки клиентами некорректных запросов приложения Windows DNA могут применять другой специальный тип бизнес-объектов, позволяющих клиентам генерировать корректные запросы. Так, подобные объекты могут содержать данные, необходимые клиенту для создания запросов, например результаты выполнения запросов к базе данных или код проверки корректности запросов клиента. В некоторых случаях такие объекты могут быть получены клиентским приложением от приложений промежуточного звена.
|
|
Требования к приложениям Windows DNA
Одним из основных требований к приложениям Windows DNA является надежность. Приложение считается надежным, если оно поставляет корректные результаты при обслуживании многих пользователей. Приведем пример. Представьте себе двух пользователей, заказывающих на складе одну и ту же партию товара. Оба клиентских приложения обращаются к базе данных склада, убеждаются в том, что данная партия товара доступна, оформляют заказ, выполняя необходимые финансовые операции, и помечают данную партию как заказанную. В результате производятся два заказа и два платежа за одну и ту же партию товара. Очевидно, что такой результат некорректен.
Для того чтобы гарантировать корректность результата, бизнес-объект должен выполнить эту операцию подобно тому, как выполняются транзакции в базах данных серверных СУБД («Введение в базы данных. Часть 1», КомпьютерПресс № 3’2000). Если мы расширим понятие транзакции применительно к областям, не связанным с базами данных, мы можем сказать, что транзакция — это набор операций, которые либо выполняются вместе, либо не выполняются вообще.
В Windows DNA транзакции считаются критическими ресурсами, поскольку они блокируют записи в базах данных и иные ресурсы. Это означает, что клиенты не должны непосредственно манипулировать ими.
Приложения, критичные для бизнеса, должны быть доступны, то есть способны обслуживать запросы клиентов в любое время. Доступность таких приложений зависит от доступности как аппаратного, так и программного обеспечения. Чтобы повысить доступность приложений, создаваемые приложения должны быть устойчивыми к сбоям. Одним из способов обеспечения такой устойчивости является дублирование ресурсов, сервисов и бизнес-объектов.
Использование Microsoft Message Queue Services, позволяющих отправлять содержащееся в очереди сообщение получателю до тех пор, пока оно не будет успешно доставлено или не закончится отведенное на операцию время, повышает доступность приложений Windows DNA.
Кроме того, приложения Windows DNA должны быть масштабируемыми, то есть способными обслуживать большее число клиентов за счет добавления ресурсов без увеличения среднего времени выполнения запроса клиента. Для этого приложение Windows DNA должно использовать критические ресурсы как можно меньше по времени. Так, следует избегать вовлечения пользователя в транзакцию, удерживать ресурсы только тогда, когда они действительно нужны, и высвобождать их, как только представится возможность (например, используя коллективное разделение ресурсов или объединение их в пул — resource pooling). Это возможно при применении сервисов COM+ для управления ресурсами и бизнес-объектами.
Еще одним способом достижения масштабируемости является обеспечение баланса загрузки ресурсов. Это можно сделать, применяя сервисы очереди сообщений для коммуникаций между бизнес-объектами. Тогда при увеличении числа клиентов и их запросов можно просто добавлять новые серверы. Если несколько однотипных серверов обрабатывают общую очередь запросов от разных клиентов, они оказываются равномерно загруженными. При использовании MSMQ каждый из серверов получает для обработки запрос из очереди по мере выполнения предыдущего запроса. В этом случае исключена ситуация, когда один сервер перегружен запросами, а другой при этом простаивает. Однако обеспечить баланс загрузки можно и иными способами, например с помощью сервисов, перераспределяющих клиентов между серверами случайным образом.
И наконец, четвертым требованием к приложениям Windows DNA является требование интероперабельности, то есть способности использовать ресурсы и данные платформ отличных от Windows.
|
|
Windows DNA 2000
Очередным шагом в развитии идей DNA стала концепция Windows DNA 2000 — распределенных приложений, основанных на семействе операционных систем семейства Windows 2000. Ключевая идея этой концепции — превращение Web-серверов из простых поставщиков HTML-страниц в Web-сервисы, взаимодействующие с другими путем посылки XML-сообщений. (Более подробное описание архитектуры Windows DNA 2000 можно найти в статье «Windows DNA 2000 — платформа нового тысячелетия», КомпьютерПресс № 1‘2000.)
В данной статье мы рассмотрели ограничения, существующие в приложениях, реализованных в архитектуре «клиент-сервер», ознакомились с архитектурой Microsoft Windows DNA и обсудили логические звенья этой архитектуры и возможные способы их реализации.
В следующей статье мы начнем более подробно рассматривать вопросы, связанные с практической реализацией многозвенных приложений.
Дополнительные ресурсы:
- цикл статей «Введение в базы», КомпьютерПресс № 3-12’2000;
- «Windows DNA 2000 — платформа нового тысячелетия», КомпьютерПресс № 1‘2000.
- http://www.microsoft.com/dna/;
- http://www.msdn.microsoft.com/library/psdk/bdg/BDGcover.htm/.
КомпьютерПресс 1'2001
