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

Крейг Рассел (Craig Russell) — практикующий архитектор программного обеспечения, специализирующийся на персистентности объектов (object persistence) и распределенных системах. В настоящее время paботает ведущим специалистом в компании Sun Microsystems.

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

Одна маленькая стрелка может означать: «Синхронный запрос/ответ в формате SOAP-XML через HTTP». Для одного элемента диаграммы получается слишком много информации. Места для полной записи обычно не хватает, поэтому мы помечаем стрелку надписью «XML через HTTP» (с точки зрения внутренней реализации) или «Поиск по коду товара» (с точки зрения внешних пользователей).

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

• Сетевые карты

• Сетевые коммутаторы

• Брандмауэры

• Системы обнаружения и предотвращения вторжений (IDS/IPS)

• Брокеры или очереди сообщений

• Механизмы преобразования XML

• Серверы FTP

• Зонные таблицы

• Кольца SoNET

• Шлюзы MPLS

• Магистральные линии

• Океаны

• Рыболовные траулеры, повреждающие донные кабели

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

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

Необходимо хорошо понимать, какая статическая и динамическая нагрузка ложится на каждую стрелку. Рядом с «SOAP-XML через HTTP» около стрелки стоило бы написать также: «С каждым запросом HTTP принимается одно обращение, с каждым ответом HTTP возвращается один ответ. Ожидается до 100 запросов в секунду, ответ в 99,999 % случаев должен выдаваться менее чем за 250 мс».

Но и это еще не все, что необходимо знать об этой стрелке:

• Что если вызывающая сторона обращается по ней слишком часто? Как должен действовать получатель — игнорировать запросы, вежливо отказывать или по возможности стараться их обработать?

• Что делать вызывающей стороне, если обработка запроса заняла более 250 мс? Повторить попытку? Немного подождать? Решить, что на стороне получателя произошел сбой, и продолжить работу без этой функции?

• Что произойдет, если вызывающая сторона отправила запрос по протоколу версии 1.0, а получила ответ в версии 1.1? А если вместо XML был получен код HTML? Или файл в формате MP3 вместо XML-файла?

• Что произойдет, если одна из сторон интерфейса станет временно недоступной?

Ответы на эти вопросы представляют собой суть проектирования «в пустом пространстве» диаграмм.

Биография автора приведена ранее.

В любой профессии существует свой жаргон, повышающий эффективность общения представителей этой профессии. Адвокаты говорят друг с другом о Habeas Corpus, Voir Dire и Venire, плотники — о соединениях встык и внахлест и о пропитках, а архитекторы ПО — о ROA, двухэтапном представлении и супертипах уровней…Минуточку… о чем, простите?..

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

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

Шаблоны корпоративного уровня определяют «каркас» высокоуровневой архитектуры. К числу самых распространенных архитектурных шаблонов относятся архитектура, управляемая событиями (EDA, Event-Driven Architecture), сервис-ориентированная архитектура (SOA, Service-Oriented Architecture), ресурсно-ориентированная архитектура (ROA, Resource-Oriented Architecture) и конвейерная архитектура (pipeline architecture).

Шаблоны уровня приложения описывают дизайн приложения или подсистемы в контексте более крупной корпоративной архитектуры. К этой категории относятся хорошо известные шаблоны J2EE (например, Session Facade (фасад сессии) и Transfer Object (объект перемещения)), а также шаблоны, описанные в книге Мартина Фаулера (Martin Fowler) «Patterns of Enterprise Application Architecture»[22] (Addison-Wesley Professional).

Шаблоны интеграции играют важную роль в проектировании и описании концепций, связанных тем, как компоненты, приложения и подсистемы совместно используют информацию и функциональность. Вот некоторые примеры шаблонов интеграции: общий доступ к файлам, удаленные вызовы процедур, различные шаблоны передачи сообщений. Описания этих шаблонов см. http://www.enterpriseintegrationpatterns.com/eaipatterns.html.

Знание основных шаблонов из книги «банды четырех» «Design Patterns: Elements of Reusable Object-Oriented Software»[23] (Addison-Wesley Professional) обязательно для каждого архитектора. На первый взгляд может показаться, что эти шаблоны относятся к слишком низкому для архитектора программных продуктов уровню, однако они — часть лексикона, позволяющего архитекторам и разработчикам эффективно общаться.

Архитектор должен также знать и понимать суть различных антипаттернов. Антипаттерны (термин введен Эндрю Кенигом (Andrew Koenig)) представляют собой повторяемые процессы, приводящие к неэффективным результатам. Вот хорошо известные примеры антипаттернов: Analysis Paralysis (аналитический паралич), Design By Committee (разработка комитетом), Mushroom Management (управление грибами), Death March (путь камикадзе[24]). Знание этих шаблонов поможет вам избежать многих типичных ошибок. Список распространенных антипаттернов приведен по адресу http://ru.wikipedia.org/wiki/Антипаттерн.