Лекция № 1. Проблемы проектирования сетевых приложений

Лекция № 1. Проблемы проектирования сетевых приложений
1. Проблемы сетевых приложений.
2. Аспекты проектирования сетевых приложений
Краткое содержание
Глава описывает сдвиг парадигмы проектирования, который произошел при переходе от архитектур автономных приложений к архитектурам
сетевых приложений. Этот сдвиг привел к появлению новых проблем двух
типов. Во-первых, в пространстве задач, это проблемы, связанные с проектированием и архитектурой программного обеспечения. И, во-вторых, в пространстве решений, это проблемы, связанные с инструментальными программными средствами и методами, используемыми при реализации сетевых
приложений. В этой главе сначала анализируются аспекты проектирования,
влияющие на проблемы первого типа, а затем дается представление о промежуточном слое, создание которого диктуется проблемами второго типа и который применяется для их решения. Кроме того, глава знакомит с инструментальной библиотекой АСЕ и с примером сетевого приложения, который
используется на протяжении всей книги в качестве иллюстрации предлагаемых решений.
1 Проблемы сетевых приложений
Большинству разработчиков программного обеспечения хорошо знакомы архитектуры автономных приложений, в которых один компьютер содержит все необходимые программные компоненты: графический пользовательский интерфейс (GUI), прикладную сервисную обработку и средства
хранения информационных ресурсов. Например, автономная прикладная архитектура, представленная на рис. 0.1, объединяет GUI, прикладную обработку и хранение информационных ресурсов на одном компьютере, к которому напрямую под-
ключены периферийные устройства. Поток управления автономного приложения реализуется исключительно на том компьютере, на котором выполнение началось.
Архитектуры сетевых приложений разделяют прикладную систему на
службы (services), которые могут совместно и многократно использоваться
множеством приложений. Чтобы повысить эффективность и полезность
служб, их распределяют по множеству вычислительных устройств, подклю1
ченных к сети, как показано на рис. 0.2. Обычные сетевые услуги, которые
предоставляются клиентам (clients) в такого рода средах, включают распределенную систему именования, сетевые файловые системы, управление таблицами маршрутизации, регистрацию, печать, электронную почту, дистанционный вход в систему, передачу файлов, службы электронной коммерции на
базе Web, обработку платежей, организацию взаимосвязей с клиентами, системы «справочных столов», обмен МРЗ, потоковое медиа, обмен сообщениями в реальном времени, групповые чаты.
Архитектура сетевых приложений, показанная на рис. 0.2, распределяет реализацию интерактивного GUI, обработку запросов на обслуживание и
хранение информационных ресурсов среди множества независимых хостов
сети. Во время выполнения сетевого приложения поток управления реализуется или на одном, или на нескольких хостах. Все компоненты такой системы
обмениваются информацией, передавая друг другу данные и управление потоком по мере необходимости. Если использовать совместимые протоколы
обмена информацией, то можно добиться взаимодействия отдельных компонент, даже если базовые сети, операционные системы, аппаратные средства и
языки программирования являются неоднородными [HV99]. Такое разделение ответственности за реализацию прикладной сетевой службы среди множества хостов может иметь следующие преимущества:
1. Усовершенствованные взаимосвязь и взаимодействие способствуют быстрому распространению информации большему числу потенциальных пользователей. Наличие взаимосвязи освобождает от необходимости
переносить информацию вручную и создавать дубликаты.
2. Улучшенные производительность и масштабируемость дают
возможность легко, не нарушая устойчивости, изменять конфигурации систем
2
с целью балансировки вычислительных ресурсов в соответствии с текущими
и прогнозируемыми системными требованиями.
3. Сокращение затрат за счет того, что пользователи и приложения
могут совместно использовать дорогостоящие периферийные устройства и
программное обеспечение, например, сложные системы управления базами
данных.
Ваша работа в качестве разработчика сетевых приложений заключается
в том, чтобы понять какие службы будут обеспечивать работу ваших приложений и в какой, или каких, из существующих сред они могут быть реализованы, а затем:
1. Спроектировать механизмы, которые будут использоваться службами для организации взаимодействия между собой и с клиентами.
2. Выбрать архитектурные решения и способы организации служб такие, чтобы они наиболее эффективно использовали существующие среды.
3. Реализовать эти решения, используя методы и средства, которые исключают сложность и позволяют разрабатывать корректное, расширяемое,
высокопроизводительное, не требующее значительных усилий на сопровождение программное обеспечение, необходимое для достижения стоящих перед вами целей.
Эта книга предоставляет информацию и средства, необходимые вам
для того, чтобы преуспеть в решении этих задач.
Ваша работа не будет легкой. Сетевые приложения, как правило, гораздо сложнее проектировать, программировать, отлаживать, оптимизировать и контролировать, чем их автономные аналоги. Нужно научиться преодолевать собственную и «случайную» сложность [Вго87], которые связаны
с разработкой и конфигурированием сетевых приложений. Собственная
сложность (inherent complexities) связана с ключевыми проблемами предметной области (domain), затрудняющими разработку сетевого приложения,
включая:
• Выбор подходящих механизмов коммуникаций и создание протоколов для их эффективного использования.
• Проектирование сетевых служб, которые рационально используют
доступные вычислительные ресурсы и снижают затраты на последующее сопровождение.
• Эффективное использование параллелизма (concurrency) для достижения предсказуемой, надежной и высокой производительности вашей системы.
• Размещение и конфигурирование служб, увеличивающее, насколько
это возможно, работоспособность и гибкость системы.
Преодоление собственной сложности требует опыта и основательного
понимания самой предметной области. Существует много альтернатив проектирования, имеющих отношение к проблемам собственной сложности, мы
будем их рассматривать в главах 1 и 5.
«Случайная» сложность (accidental complexities) вытекает из ограничений, связанных с инструментальными средствами и методами, применяе3
мыми для разработки программного обеспечения сетевых приложений,
включая:
• Отсутствие в ОС собственных типобезопасных (type-safe), переносимых и расширяемых API.
• Широко распространенное применение алгоритмической декомпозиции, что делает неоправданно трудными поддержку и развитие сетевых приложений.
• Непрерывный процесс открытий и изобретений основных концепций
и возможностей сетевых приложений удерживает затраты, связанные с жизненным циклом программного обеспечения, на излишне высоком уровне.
Разработчики сетевых приложений должны понимать эти проблемы и
применять эффективные методы борьбы с ними. На всем протяжении этой
книги мы показываем на примерах как АСЕ использует объектно-ориентированные методы и возможности языка C++, чтобы справиться с этой «случайной» сложностью.
2 Аспекты проектирования сетевых приложений
Можно научиться программировать API и интерфейсы, не вникая в
ключевые аспекты проектирования предметной области. Тем не менее, как
следует из нашего опыта, разработчики с более глубоким знанием предметной области сетевого приложения гораздо лучше подготовлены к эффективному решению ключевых проблем, связанных с проектированием, реализацией и производительностью. Поэтому, в первую очередь, мы исследуем основные архитектурные аспекты проектирования, связанные с разработкой сетевых приложений. Больше внимания мы уделяем серверам, которые поддерживают множество служб или множество экземпляров одной службы и
обслуживают одновременно множество клиентов, как в показанной на рис.
0.2 среде сетевых приложений.
Аспекты проектирования, обсуждаемые в этой книге, были определены
путем всестороннего анализа предметной области (domain analysis), основанного на реальных проектах и опыте реализации сотен корпоративных сетевых приложений и систем, разработанных за последнее десятилетие. Анализ предметной области является индуктивным процессом с обратными связями, систематически исследующим предметную область с целью выявления
ее основных проблем и аспектов проектирования и выработки на этой основе
эффективных методов решения. Этот процесс дает следующие преимущества:
• Определяет общий словарь абстракций предметной области, что
позволяет разработчикам более эффективно общаться друг с другом [Fow97].
В свою очередь, уточнение словаря предметной области упрощает его отображение на соответствующий набор паттернов и программных абстракций в
области решений. Например, общее понимание сетевых протоколов, стратегий демультиплексирования событий и архитектур параллелизма позволяет
нам применить эти концепции к обсуждению интерфейсных фасадов (wrapper facades) и каркасов (frameworks) АСЕ в [SH].
4
• Улучшает повторное использование путем разделения анализа проекта на две составляющие:
1. Специфичную для конкретных типов приложений.
2. Общую для всех приложений данной предметной области.
Сосредоточившись на общих для предметной области вопросах проектирования, разработчики приложений и промежуточного слоя могут выявить
возможности для адаптации или для создания библиотек классов повторно
используемого программного обеспечения. После разложения канонических
потоков управления по библиотекам классов и их реинтеграции, они могут
создать каркасы промежуточного слоя, такие как в АСЕ, которые могут существенно снизить объем работы при разработке приложений в дальнейшем.
В сформировавшейся предметной области задачи проектирования, отражающие специфику приложения, могут решаться на систематической основе
путем расширения и настройки существующих каркасов промежуточного
слоя средствами объектно-ориентированного языка, такими как наследование, динамическое связывание, параметризованные типы и исключения.
В области сетевых приложений разработчики встречаются с проектными решениями каждого из четырех аспектов, изображенных на рис. 0.3. Эти
аспекты проектирования касаются, в основном, борьбы с собственной сложностью предметной области. Поэтому они в значительной степени независимы от процессов, связанных с жизненным циклом, от методов и нотаций проектирования, от языков программирования, от платформ операционных систем и от сетевых аппаратных средств. Каждый из этих аспектов проектирования состоит из набора относительно независимых альтернатив. Хотя они
по большей части независимы друг от друга, изменение одной или нескольких альтернатив сетевого приложения могут соответственно изменить всю
его «форму». Следовательно, изменения дизайна не могут осуществляться
изолировано. Имейте это в виду, анализируя следующие аспекты проектирования:
1. Аспекты коммуникаций касаются правил, формы и уровня абстракции, которые сетевые приложения используют при взаимодействии.
2. Аспекты параллелизма касаются механизмов и стратегий правильного использования процессов и потоков для представления множества экземпляров служб, а также того, каким образом каждый экземпляр службы
может внутри себя использовать множество потоков.
3. Аспекты служб касаются ключевых свойств сетевых прикладных
служб, таких как время существования и структура каждого экземпляра
5
службы.
4. Аспекты конфигурации касаются идентификации сетевых служб, а
также того, в какой момент времени они объединяются для формирования
законченных приложений. Аспекты конфигурации часто затрагивают несколько служб, а также связи между ними.
Мы рассмотрим первые две группы аспектов более подробно в главах 1
и 5 соответственно, а третью и четвертую обсудим в [SH]. Сначала мы рассмотрим основной словарь, альтернативы проектирования и абстракции решений, затем возможности платформ относительно каждого аспекта, связанную с ними «случайную» сложность, и решения, которые предлагает АСЕ.
Как вы увидите, АСЕ использует апробированную объектноориентированную декомпозицию, дизайн интерфейсов, паттерны, инкапсулирующие данные, и возможности языка C++, чтобы дать возможность аспектам проектирования ваших сетевых приложений изменяться настолько
независимым и переносимым образом, насколько это возможно.
6