Открытая архитектурная модель

Открытая архитектурная модель

Утвержденный Международной организацией по стандартизации (ISO) стандарт Reference Model for Open Distributed Processing (RM-ODP) (Эталонная модель открытой распределенной обработки) определяет эталонную модель для разработки распределенных системных архитектур. Модель RM-ODP можно рассматривать как метастандарт, рамочную модель архитектурных концепций и терминологии, облегчающую разработку стандартов в области ресурсных ИТ-услуг. В этой главе дается краткое описание модели RM-ODP и иллюстрируются некоторые аспекты ее применения для построения архитектурных моделей ресурсных ИТ-услуг.
Модель RM-ODP.
Модель RM-ODP включает пять точек зрения на распределенную компьютерную систему. Эти точки зрения представляют интересы различных заинтересованных сторон — создателей, владельцев, пользователей, эксплуатирующей организации и т.д. В совокупности эти точки зрения образуют полную архитектуру системы. Поскольку интересы разных заинтересованных сторон сосредоточены на разных моментах времени, эти точки зрения также дают хорошее представление о жизненном цикле системы. На Рис. A-1 показаны пять точек зрения RM-ODP применительно к ресурсной модели ИТ-услуг, а также проиллюстрирован тот факт, что ресурсная ИТ-служба существует в определенной среде, ограничивающей ее поведение.
Рис. A-1: Использование эталонной модели RM-ODP для моделирования ресурсной ИТ-службы
Здесь пять указанных точек зрения представляют следующие стороны: Точка зрения предприятия. Точка зрения владельцев (высшего руководства) ресурсной ИТ-службы и пользователей. Она определяет роль ресурсной ИТ-службы внутри предприятия, включая охват, политики, сообщества, контракты и взаимоотношения со средой. Эта точка зрения также определяет источники данных, с которыми имеет дело ресурсная служба.
Информационная точка зрения. Это точка зрения специалистов по информации, администраторов баз данных и других лиц, ответственных за управление информационными ресурсами предприятия. Она определяет элементы информации и их движение по предприятию, а также процессы манипулирования этими элементами.
Вычислительная точка зрения. Это точка зрения архитекторов приложений. Она определяет вычислительные объекты ресурсной службы (грубо говоря, приложения) и интерфейсы между ними. Эта точка зрения определяет контракты со средой, которые устанавливают взаимоотношения между приложениями и ресурсной ИТ-службой. Она не затрагивает физического распределения объектов между процессорами.
Инженерная точка зрения. Это точка зрения проектировщиков систем и разработчиков платформ. Она определяет инфраструктуру распределения информации в ресурсной службе (сеть), конфигурацию компьютеров и их взаимоотношения с вычислительными объектами. Эта точка зрения описывает, как бизнес-приложения используют сервисы ресурсной службы.
Технологическая точка зрения. Это точка зрения лиц, занимающихся внедрением приложений. Она определяет конкретные аппаратные, программные и сетевые технологии и их место в ресурсной ИТ-службе, а также технические стандарты и опорные точки для сравнения реализации с техническими спецификациями.
Одна из важных ролей различных точек зрения RM-ODP состоит в том, что они демонстрируют взгляды различных заинтересованных сторон на одни и те же или взаимосвязанные элементы. Например, точка зрения предприятия может определять, какими данными занимается ресурсная ИТ-служба, в то время как информационная точка зрения может определять схемы данных, а технологическая — используемые продукты для управления базами данных. Архитектор, разрабатывая архитектуру на базе RM-ODP, явным образом определяет взаимоотношения между взаимосвязанными элементами разных точек зрения, чтобы точки зрения оставались согласованными при изменениях в ходе разработки. Точки зрения остаются согласованными благодаря тому, что явные взаимоотношения между элементами наглядно показывают, когда изменение в одной точке зрения должно быть распространено на связанные элементы других точек зрения.
Из пяти точек зрения модели RM-ODP на ресурсную ИТ-службу, показанных на Рис. A-1, точки зрения предприятия, информационная и вычислительная точки зрения указывают, что делает ресурсная ИТ-служба. Они независимы от инженерной и технологической точек зрения, которые указывают, как ресурсная ИТ-служба выполняет свои задачи. В совокупности эти три точки зрения образуют эталонную архитектуру ресурсной ИТ-службы, не зависящую от обслуживаемых пользователей и технологий реализации. Эта эталонная архитектура не ограничена какими-либо инженерными или технологическими рамками. Используя эталонную архитектурную модель, технические и бизнес-аналитики могут исследовать деловые и финансовые последствия изменений политик и распространять их на инженерные и технологические точки зрения для оценки затрат и других последствий. Точка зрения предприятия, вычислительная и инженерная точки зрения не зависят от выбора технологий для ресурсной ИТ-службы.
Объекты.
Модель RM-ODP построена по объектному принципу. Как и в других объектных системах, объект RM-ODP представляет собой абстракцию, которая может представлять любую сущность, определяемую состоянием (параметрами, принимающими значения) и поведением (заданными реакциями на четко определенные воздействия). Объекты.
инкапсулируют (скрывают) значительную часть подробностей тех сущностей, которые они представляют. Они отражают только видимые извне состояние и поведение, вызываемое внешними сигналами. Объекты полезны при моделировании как бизнес-систем, так и компьютерных систем.
Объекты могут моделировать компоненты, системы и даже людей. Объекты имеют иерархическую структуру; они могут содержать другие объекты (например, центр обработки данных может содержать несколько объектов типа «компьютер»). Объект может быть большим — например, вся ресурсная ИТ-служба в целом — или небольшим, как одиночное приложение или аппаратный компонент. Очевидно, в разных точках зрения полезны разные объекты.
Задавая объекты с большей или меньшей детальностью, можно строить модели с разными уровнями точности, полноты и формальности. Высокоуровневые модели RM-ODP, представляющие все точки зрения, могут быть полезны для руководства компании, однако их можно также детализировать до уровня, на котором программист уже сможет разрабатывать программный код или компьютерная программа — предпринимать действия и создавать код без вмешательства человека.
Ресурсная ИТ-служба и модель RM-ODP.
Чтобы лучше понять ключевые аспекты эталонной модели RM-ODP в ее приложении к ресурсным ИТ-службам, в этом разделе мы проводим аналогию между поставкой электроэнергии электрической компанией и поставкой ИТ-сервисов ресурсной ИТ-службой, анализируя обе архитектуры на основе модели RM-ODP.
Поставщик электроэнергии.
На Рис. A-2 показана отопительная система (потребитель), которая использует электроэнергию (ресурс), поставляемую электрической компанией (ресурсной службой). Электричество нагревает воду, которая идет в отопительный радиатор (приложение), который, в свою очередь, дает тепло (бизнес-задача). Термостат обнаруживает падение температуры в комнате (мониторинг) и сигнализирует бойлеру о необходимости увеличить подачу тепла (запрос сервиса). Ресурсная служба отвечает на запрос, без вмешательства потребителя увеличивая подаваемую электрическую мощность. Если обитатель комнаты (руководство) решит, что термостат отрегулирован на слишком высокую или слишком низкую температуру (спрос), термостат можно отрегулировать, в результате чего потребление электроэнергии (и сумма в счете) увеличится или уменьшится.
Рис. A-2: Система отопления (Пользователь), подключенная к сети электрической компании.
(ресурсной службе)
Между электрической компанией и потребителями имеется (возможно, неявное) соглашение об уровне сервиса (SLA), которое на рисунке обозначено как «контракт со средой» по причинам, обсуждаемым ниже в этой главе. Например, компания поставляет электроэнергию при стандартном напряжении и частоте тока, вплоть до заранее согласованной мощности. Электрический ток проходит через счетчик, который регистрирует потребление для выставления пользователю счетов.
Руководство отопительной системы (приложения) покупает ресурс (электроэнергию), чтобы решать бизнес-задачу (обогревать помещения). Если ресурсная компания может поставлять электроэнергию большому количеству отопительных систем (а также телевизоров, тостеров и других приложений) надежнее и дешевле, чем это делали бы частные электрогенераторы, ее бизнес будет успешным.
Пользователи в данном примере входят в состав сообщества, которое объединяет все дома и компании, обслуживаемые электростанцией. Сообщество представляет собой федерацию — его члены независимы друг от друга в большинстве аспектов, однако в некоторой степени сотрудничают для поддержания надежной поставки электроэнергии всем членам сооб-.
щества. Электростанция также может быть частью более крупного федеративного сообщества — обычно все электростанции электрической компании соединены между собой и могут направлять электроэнергию туда, где она необходима. Существует также федерация электрических компаний, в некоторой степени подобная Grid-сети, обсуждавшейся в Главе 4, которая позволяет динамически обмениваться ресурсами в еще большем масштабе. Концепция федераций пользователей и управляющих ими правил имеет большое значение для архитектуры ресурсной службы, поскольку пользователи определенных сервисов по сути представляют собой федерации с общими интересами.
Федерация — это определенный тип сообщества ODP, в котором различные группы, в норме подчиненные разным руководствам, соглашаются сотрудничать для решения определенной задачи. Поскольку реализация ресурсной ИТ-службы предполагает множество слияний управляемых раздельно подсистем ради достижения общих интересов, правила, определяющие создание и функционирование федераций и взаимодействие между ними, являются важной частью технического плана ресурсной службы.
Электрические компании имеют политики, ограничивающие среду, в которой эти компании функционируют. Например, пользователям не разрешается манипулировать счетчиками; их также могут обязать предоставлять представителям компании доступ к счетчикам на своей территории. В ответ компания обязуется предоставлять электроэнергию, отвечающую определенным техническим требованиям; кроме того, для компании могут быть установлены тарифы на электроэнергию для различных категорий потребителей (например, жилого сектора и промышленности).
Ресурсная ИТ-служба.
На Рис. A-3 показана бизнес-функция (потребитель
), которая потребляет вычислительные мощности и емкости хранения (ресурсы) поставляемые вычислительным центром (ресурсной службой). Компьютеры исполняют программы обработки данных (приложения), регистрируя продажи или обслуживая клиентов (бизнес-задача). Измерительные приложения обнаруживают ухудшение времени отклика (мониторинг) и сигнализируют консоли управления о необходимости увеличить предоставление вычислительных мощностей (запрос сервиса). В идеале ресурсная служба отвечает на этот запрос без вмешательства потребителя. Если подразделение компании (руководство) решит, что надо быстрее обслуживать большее количество пользователей (спрос), объем предоставляемых ресурсов можно увеличить или уменьшить, в результате чего потребление ресурсов (и сумма в счете) увеличится или уменьшится.
Рис. A-3: Бизнес-приложение (Пользователь), подключенное к ресурсной ИТ-службе
Руководство бизнес-функции покупает ресурсы (вычислительные мощности и емкости хранения), чтобы решать бизнес-задачу (обработка данных). Если ресурсная служба может поставлять эти ресурсы большому количеству бизнес-подразделений (и организационных подразделений) надежнее и дешевле, чем это делали бы компьютерные системы уровня подразделения, ее работа будет успешной.
Как и электрическая компания, ресурсная ИТ-служба также связана разрешениями, обязательствами и запретами, которые ограничивают ее действия и действия ее потребителей в рамках среды ее функционирования. Например, руководство предприятия может потребовать, чтобы ресурсная ИТ-служба обеспечивала уровень готовности вычислительных систем и сервисов оперативного хранения в 99.999%, даже если это не вполне оправданно с экономической точки зрения. Со своей стороны, пользователи могут быть ограничены обязательными мерами безопасности или запретами хранить на ресурсах хранения ИТ-службы файлы формата MP3 или JPG.
Ресурсная ИТ-служба и спрос.
По мере роста потребностей в приложении растет и объем ИТ-ресурсов, необходимых для поддержания адекватной производительности. Ресурсная служба поставляет эти дополнительные ресурсы — или на постоянной основе (например, емкости хранения для увеличившейся базы данных клиентов), или временно (например, временные емкости хранения для составления годового или месячного отчета). Временно предоставленные ресурсы по истечении срока пользования возвращаются в пул ресурсов ИТ-службы.
В идеале ресурсная ИТ-служба предоставляет подобные дополнительные ресурсы и сервисы по требованию, в реальном времени и прозрачно для пользователей, исходя из соглашений об уровне сервиса (SLA), которые устанавливают четко определенные политики в отношении производительности и готовности. Если менеджеру бизнес-подразделения потребуется большая или меньшая производительность, SLA может быть пересмотрено. Измерительное оборудование ресурсной ИТ-службы регистрирует фактическое потребление для каждого пользователя и выставляет счета за реально потребленные ресурсы.
Ресурсная ИТ-служба более гибка, чем электрическая компания, в том смысле, что ей легче менять типы предоставляемых ресурсов. Если, например, со стороны подразделений компании возникнет активный спрос, скажем, на Linux-серверы, ресурсная ИТ-служба может добавить их с список своих сервисов. Вопрос предоставления той или иной услуги зависит скорее от критериев бизнеса, чем от физических ограничений.
Оба приведенных примера были смоделированы с использованием концепций и в некоторой степени терминологии модели RM-ODP. Роль RM-ODP состоит в абстрагировании внутренних сущностей объектов, участвующих в модели. Например, ресурсная ИТ-служба обычно имеет в своем составе объект, служащий для развертывания ресурсов. Это может быть как человек, так и, в более развитой ресурсной службе, автоматизированное программное обеспечение. Замена людей или программных модулей объектами позволяет создавать более гибкие и подготовленные к развитию архитектуры.