как непосредственный контакт, но в действительности им не является. Пустота между прямоугольниками заполнена аппаратными и программными компонентами. В частности, здесь могут находиться:
Сетевые карты
Сетевые коммутаторы
Брандмауэры
Системы обнаружения и предотвращения вторжений (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-файла?
Что произойдет, если одна из сторон интерфейса станет временно недоступной?
Ответы на эти вопросы представляют собой суть проектирования «в пустом пространстве» диаграмм.
Биография автора приведена ранее.
Изучите профессиональный жаргон Марк Ричардс
Очень важно, чтобы архитекторы ПО независимо от платформы, на которой они работают, располагали эффективными средствами общения друг с другом. Одним из таких средств являются архитектурные шаблоны и шаблоны проектирования. Чтобы эффективно работать в качестве архитектора, необходимо понимать базовые архитектурные шаблоны
и шаблоны проектирования, различать их в коде, знать, когда они применяются, и уметь использовать их в разговоре с другими архитекторами и разработчиками.
Архитектурные шаблоны и шаблоны проектирования можно разделить на четыре основные категории: шаблоны корпоративного уровня, шаблоны уровня приложения, шаблоны интеграции и шаблоны проектирования. Эти категории обычно определяются уровнем абстракции шаблона в общей архитектуре. Шаблоны корпоративного уровня относятся к высокоуровневой архитектуре, тогда как шаблоны проектирования относятся к структуре и поведению отдельных компонентов общей архитектуры.
Шаблоны корпоративного уровня определяют «каркас» высокоуровневой архитектуры. К числу самых распространенных архитектурных шаблонов относятся архитектура, управляемая событиями (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» (Addison-Wesley Professional).
Шаблоны интеграции играют важную роль в проектировании и описании концепций, связанных тем, как компоненты, приложения и подсистемы совместно используют информацию и функциональность. Вот некоторые примеры шаблонов интеграции: общий доступ к файлам, удаленные вызовы процедур, различные шаблоны передачи сообщений. Описания этих шаблонов см. (Addison-Wesley Professional) обязательно для каждого архитектора. На первый взгляд может показаться, что эти шаблоны относятся к слишком низкому для архитектора программных продуктов уровню, однако они часть лексикона, позволяющего архитекторам и разработчикам эффективно общаться.