И. Соммервилл - Инженерия программного обеспечения (1133538), страница 60
Текст из файла (страница 60)
Проектирование сервером, на котором выполняется приложение, и серверами баз данных. Объединяющий сервер собирает распределенные данные и представляет их в приложении таким образом, будто они находятся в одной базе данных. Рис. 11.В. РпспРедеапсппя аРхи оииоеуРп банковской сиоаеим с испаеыовпииси 1пеегпеьо4еви сов Таблица 11.2. Применение разных тивов архитектуры клиент/сервер Приложения Архитектура Иаследуемые системы, в которых нецелесообразно разделять выполнение приложенил и управления данными. Приложения с интенсивными вычислениями, например ком- пнллторы, но с незначительным обьемом управления данными.
Приложения, в которых обрабатываются большие массивы данных (запросы), но с небольшим объемом вычислений в са- мом приложении Приложения, где пользователю требуется интенсивная абра. боткз данных (вапример. визуализация данных или большие объемы вычисления). Двухуровневая архитек- тура топкого клиента Двухуровпеваяархитек- тура толстого клиента Приложения с относительно постоянным набором функций на стороне пользователя, применлемых в среде с хорошо от- лаженным системным управлением Большие приложения с сотнями и тысячами клиентов. Трехуровневая и много- уровневая архитектуры клиент/сервер Приложения, в которых часто меняются и данные, и методы обработки. Приложения, в которых выполняется интеграция данных из многих источников Разработчики архитектур клиент/сервер, выбирая наиболес подходящую, должны учитывать ряд факторов.
В табл. 11.2 перечислены различпыс случаи применения архитектуры клиент/сервер. 11. Архитектура распределенных систем 235 11.3. Архитектура распределенных объектов В модели клиент/сервер распределенной системы между клиентами и серверами сушествуют различия. Клиент запрашивает сервисы только у сервера, но не у др)тих клиентов; серверы могут функционировать как клиенты и запрашивать сервисы у других серверов, но не у клиентов; клиенты должны знать о сервисах, предоставляемых определенными серверами, и о том, как взаимодействуют эти серверы.
Такая модель отлично подходит ко многим типам приложений, но в то же время ограничивает разработчиков системы, которые вынуждены решать, где предоставлять сервисы. Они также должны обеспечить поддержку масштабируемости и разработать средства включения клиентов в систему на распределенных серверах. Более общим подходом, применяемым в проектировании распределенных систем, явллстся стирание различий между клиентом и сервером и проектирование архитектуры системы как архитектуры распределенных объектов. В этой архитектуре (рис. 11.9) основными компонентами системы являются объекты, предоставляющие набор сервисов через свои интерфейсы. Другие объекты вызывают эти сервисы, не делая различий между клиентом (пользователем сервиса) и сервером (поставщнком сервиса).
Рис. П. й /грхиэнкжурл фпс предвоенных обмкэгов Объекты могут располагаться на разных компьютерах в сети и взаимодействовать посредством промежуточного ПО. По аналогии с системной шиной, которал позволяет подключать различные устройства и полдерживать взаимодействие между аппэратпымн средствами, промежуточное ПО лгожно рассматривать как агину программного обеспечения. Она предоставляет набор сервисов, позволяющий объектам взаимодействовать друг с другом, добавлять или удалять их из системы. Промежуточное ПО называют брокером заиро. сов к объектам. Его задача- обеспечивать интерфейс между объектами. Брокеры запросов к объектам рассматриваютсл в разделе 11.4.
Ниже перечислены основные преимущества модели архитектуры распределенных объектов. ° Разработчики системы мо~ут не спешить с принятием решений относительно того, где и как будут предоставляться сервисы. Объекты, предоставляющие сервисы, могут выполняться в любом месте (узле) сети. Следовательно, различие между моделями 236 х1асть П1. Проектирование толстого и тонкого клиентов становятся несущественными, так как нет необходимо. сти заранее планировать размещение объектов для выполнения приложения. ° Системная архитектура достаточно открыта, что позволяет при необходимости добавлять в систему новые ресурсы. В следующем разделе отмечается, что стандарты программной шины постоянно совершенствуются, что позволяет объектам, написанным на разных языках программирования, взаимодействовать и предоставллть сервисы друг другу.
° Гибкость и масштабируемость системы. Для того чтобы справиться с системными нагрузками, можно создавать экземпляры системы с одинаковыми сервисами, которые будуг предоставляться разными объектами или разными экземплярамн (копиями) объектов. При увеличении нагрузки в систему можно добавить новые объекты, нс прерывая при этом работу других ее объектов. ° Существует возможность динамически переконфигурировать систему посредством объектов, мигрирующих в сети по запросам. Объекты, предоставляющие сервисы, мокнут мигрировать на тот же процессор, что и объекты.
запрашивающие сервисы, тем самым повышая производительность системы. В процессе проектирования систем архитектуру распределенных объектов можно использоватьь двояко. 1. В виде логической модели, которая позволяет разработчикам структурировать и спланировать систему. В этом случае функциональность приложения описывается только в терминах и комбннацилх сервисов. Ветен разрабатываются способы предоставления сервисов с помощью нескольких распределенных объектов. На этом уровне, как правило, проектируют крунномодульные объекты, которые предоставляют сервисы, отражающие специфику конкрстпой области приложения. Например, в программу учета розничной торговли можно включить объекты, которые бы вели учет сосгояния запасов, отслеживали взаимодействие с клиентами, классифицировали товары и др.
2. Как гибкий подход к реализации систем клиент/сервер. В этом случае логичсскал модель системы — это модель клиент/сервер, в которой клиенты и серверы реализованы как распределенные объекты, взаимодействующие посредством программной шины. При таком подходе легко заменить систему, например двухуровневую на многоуровневую. В этом случае ни сервер, пи клиент не мопгг быть реализованы а одном объекте„однако могут состоять из множества небольших объектов, каждый из которых предоставляет определенный сервис. Примером системы, которой подходит архитектура распределенных объектов, может служить система обработки данных, хранящихся в разных базах данных (рис.
11.10). В этом примере любую базу данных можно представить как объект с интерфейсом, прсдоставллющим доступ к данным "только чтение". Калсдый из объектов-интеграторов занимается определенными типами зависимостей между данными, собирая информацию из баз данных, чтобы попытаться проследить эти зависимости. Объекты-визуализаторы взаимодейств)ют с объектами-интеграторами для прсдсгавле. ния данных в графическом виде либо для составления отчетов по анализируемым данным.
Способы представление графической информации рассматриваются в главе 15. 1П Архитектура распределенных систем 237 Рис 11, 10. ДРхитекюуРоУеоепУиоелеилой сисэимм обРабомки длнимх Для такого типа приложений архитектура распределенных объектов подходит больше, чем архитектура клиент/сервер, по трем причинам. 1. В этик системах (э отличие, например, от системы банкоматов) нет одного поставщи- ка сервиса, на котором были бы сосредоточены все сервисы управления данными. 2. Можно увеличивать количество доступных баз данных, не прерывал работу системы, поскольку каждая база данных предстааллет собой просто объект. Эти объекты поддерживают упрощенный интерфейс, который управляет доступом к данным.
Доступные базы данных можно разместить на разных машинах. 3. Посредством добавления новых объектов-интеграторов можно отслеживать новыс типы зависииостей между данными. Главным недостатком архитектур распределенных объектов является то, что их сложнее проектировать, чем системы клиент/сервер. Оказывается, что системы кли.
ент/сервер предоставляют более естественный подход к созданию распределенных систем. В нем отражаются азаниоотношения между людьми, при которых одни люди пользуются услугами лругих людей, специализирующихся на предоставлении конкретных услуг. Намного труднее разработать систему в соответствии с архитектурой распределенных объектов, поскольку индустрия создания ПО пока еще не накопила достаточного опыта в проектировании и разработке крупноиодульных объектов. 11.4. СОКВА Как уже отмечалось в предыдущем разделе, при реализации архитектуры распределенных объектов необходимо промежуточное программное обеспечение (брокеры запросов к объектам), организующее взаимодействие между распределенными объектами.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
