прр. Технологическая архитектура. Основное назначение технологической архитектуры
 Скачать 4.59 Mb.
|
|
Основное назначение технологической архитектуры - это обеспечение надежных ИТ-сервисов, предоставляемых в рамках всего предприятия в целом и координируемых централизованно, как правило, департаментами информационных технологий. Технологическая архитектура определяет набор принципов и стандартов (индустриальных стандартов; стандартов, связанных с продуктами; конфигураций), которые обеспечивают руководства по выбору и использованию таких технологий как аппаратные платформы, операционные системы, системы управления базами данных, средства разработки, языки программирования, ПО промежуточного слоя, сервисы электронной почты, каталоги, системы безопасности, сетевая инфраструктура и т.д. В зависимости от особенностей организации отдельные аспекты (безопасность, интеграция, иногда разработка) могут быть выделены в отдельные области (домены) архитектуры предприятия. Технологическая инфраструктура предприятия располагается на нескольких "уровнях" и принятие решения о размещении той или иной части инфраструктуры в масштабе предприятия или отдельных бизнес-подразделений является стратегическим решением, которое должно основываться на принятых в организации принципах построения архитектуры. Gartner называет в технологической архитектуре шесть архитектурных компонент (сервисов), в каждом из которых выделяется определенное количество технологических "строительных блоков" (bricks): Сервисы данных: системы управления базами данных (технологии баз данных и методы доступа к базам), хранилища данных (хранилища и витрины данных), системы поддержки принятия решений (Business Intelligence - средства анализа и средства подготовки отчетов). Прикладные сервисы: языки программирования (языки для программирования серверной части, языки для программирования клиентской части, интегрированные среды), средства разработки приложений (средства моделирования баз данных, репозитории, методики разработки приложений, средства обеспечения качества), системы коллективной работы (средства групповой работы и электронной почты, средства управления документами), архитектура приложений (модель компонент, серверы приложений, серверы поддержки тонких клиентов), геоинформационные системы и средства. Программное обеспечение промежуточного слоя (middleware). Вычислительная инфраструктура: операционные системы и аппаратное обеспечение (приложения для настольных систем, операционные системы для настольных систем, мобильные устройства - ноутбуки, беспроводные устройства, персональные цифровые помощники, серверы приложений/данных, сетевые операционные системы, принтеры), среда для web-инфраструктуры (браузеры, web-порталы, web-серверы, средства управления и создания контента, серверы каталогов, форматы публикации информации), системы хранения (Storage Area Network - сети хранения данных, накопители на магнитных лентах, накопители на оптических дисках и CD, системы хранения высокой надежности RAID), средства системного управления (средства сетевого управления, администрирование IP), топологии (топология распределенных приложений). Сетевые сервисы: локальные сети (протоколы, кабельные системы, топология), глобальные сети (транспорт, протоколы), технологии доступа (пользователи с удаленным доступом, эмуляция терминалов и шлюзы, беспроводные технологии для локальных и глобальных сетей, интегрированные средства передачи данных и голоса, обеспечение доступности, средства видеоконференций), голосовые технологии (голос/данные поверх IP-протокола, голосовая почта), сетевое аппаратное обеспечение (концентраторы, маршрутизаторы и пр.). Сервисы безопасности: авторизация, аутентификация (внутренняя и внешняя аутентификация, PKI), сетевая безопасность (Network Firewall, Internet Firewall), физическая безопасность центров обработки данных, прочие сервисы безопасности (обнаружение вторжений, защита от вирусов). Взаимосвязи функциональных и операционных требований с архитектурой приложений и технологической архитектурой Функциональные требования к прикладной системе описывают ту ценность, которую представляет система с точки зрения реализации функций организации (бизнес-ценность). Архитектура приложений, по сути дела, является архитектурой всех автоматизированных сервисов, которые обеспечивают и реализуют такие функциональные требования, включая интерфейсы к бизнес-приложениям и другим прикладным системам. Она описывает структуру приложений и то, как эта структура реализует функциональные требования организации. Взаимосвязи функциональных и операционных требований с архитектурой приложений и технологической архитектурой Операционные (или эксплуатационные) требования к программной системе специфицируют такие аспекты, как надежность, управляемость, производительность, безопасность, совместимость. И это далеко не полный список. Примерами операционных требований являются возможность доступа к системе только авторизованных пользователей, уровень доступности прикладной системы 99,99% времени и т.д. Технологическая архитектура является архитектурой инфраструктуры аппаратного и программного обеспечения, которая обеспечивает работу прикладных систем и выполнение операционных (нефункциональных) требований, предъявляемых к архитектуре прикладных систем и информации. Она описывает структуру и взаимосвязи между используемыми технологиями и то, как эти технологии обеспечивают выполнение операционных требований организации. ГЛАВНОЕ Функциональные требования обеспечиваются архитектурой приложений, операционные требования обеспечиваются технологической архитектурой. Хорошая архитектура приложений должна эффективно использовать технологическую архитектуру, чтобы обеспечить должный уровень соответствия всем операционным требованиям. Хорошая технологическая архитектура должна быть построена с учетом поддержки прикладных систем, играющих важную роль в работе организации. Оценка состояния и требований к технологической инфраструктуре в контексте бизнес-стратегии Для оценки состояния технологической инфраструктуры предприятия в терминах, понятных бизнес-руководству, и с точки зрения потенциальных возможностей реализации различных бизнес-стратегий, можно использовать подход, предложенный Питером Кином (Peter Keen). Он основан на использовании двух критериев: Функциональные возможности: возможности по выполнению бизнес-активностей, начиная с простых, таких как пересылка информации (сообщений), до выполнения сложных транзакций, которые могут производиться совместно сотрудниками, а также поставщиками и клиентами; Охват: физические места расположения и группы людей, которые инфраструктура способна объединить, начиная от отдельного подразделения и до уровня отдельного сотрудника, где бы он ни находился. Охват и функциональные возможности инфраструктуры Адаптивная технологическая инфраструктура Одним из перспективных направлений развития технологической инфраструктуры является создание адаптивной технологической инфраструктуры, которая способна в определенных пределах, автоматически или полуавтоматически, «подстраиваться под требования» со стороны бизнес-приложений для обеспечения оптимальной работы. Основными характеристиками адаптивной системы являются: самоконфигурирование – организация системы в соответствии с требованиями; самозащита – предотвращение сбоев в системе в результате нарушения работы компонент системы и потери целостности данных; самовосстановление – диагностика неисправностей, локализация ошибок и устранение их последствий; самооптимизация – наиболее рациональное использование имеющихся ресурсов без вмешательства оператора. Адаптивная технологическая инфраструктура Основные идеи адаптивной инфраструктуры таковы: Все ИТ-ресурсы являются общими и разделяемыми; Выделение ресурсов конкретным приложениям производится автоматически в соответствии с требованиями бизнеса; Качество обслуживания является предсказуемым и стабильным, несмотря на непредсказуемый спрос на ресурсы. Инфраструктура реального времени Шаблоны информационных технологий Когда мы говорим о шаблонах, то речь не идет о конкретных моделях аппаратного или программного обеспечения. Как показано на рисунке, интерес представляет другое: Как серверы взаимодействуют между собой и как они совместно обеспечивают работу с системой клиента, использующего персональный компьютер? Какие роли играет каждый компонент? Какие типы коммуникаций необходимы между ними? Шаблоны информационных технологий Собственно шаблоны строятся на основе набора предварительно определяемых общих служб, которые могут входить в шаблон в необходимой комбинации. Примерами таких общих служб являются: преобразование данных (в частности, объединение/разделение, подстановки, округления, перевод c языка на язык, использование XSL для преобразования XML→XML и т.п); маршрутизация сообщений (в том числе оптимизация маршрута, мультипликация/демультипликация для доставки один-ко-многим, динамическая маршрутизация в зависимости от содержания и т.п .); гарантированная доставка; репозиторий сообщений и метаданных; управление транзакциями, в том числе распределенными; планирование задач и активностей; журналирование и аудит; управление нагрузкой (в том числе поддержка кластеров, динамическая балансировка, горячая замена и т.п .); управление системами, в том числе обнаружение ошибок, мониторинг параметров; служба каталогов; безопасность, включая шифрование данных. Сервис-ориентированная архитектура и архитектура, управляемая моделями При большом количестве автономных информационных систем на предприятии (или в рамках нескольких предприятий, объединенных в целую партнерскую цепочку) возникнет острая необходимость в их интеграции и взаимодействии. Для решения этих проблем предложено две архитектурных модели: сервисная модель взаимодействия между приложениями общей системы в рамках так называемой сервис-ориентированной архитектуры (Service-oriented architecture SOA); "управляемая моделями" (модельная архитектура) - Model-driven architecture (MDA). Сервис-ориентированная архитектура и архитектура, управляемая моделями При большом количестве автономных информационных систем на предприятии (или в рамках нескольких предприятий, объединенных в целую партнерскую цепочку) возникнет острая необходимость в их интеграции и взаимодействии. Для решения этих проблем предложено две архитектурных модели: сервисная модель взаимодействия между приложениями общей системы в рамках так называемой сервис-ориентированной архитектуры (Service-oriented architecture SOA); "управляемая моделями" (модельная архитектура) - Model-driven architecture (MDA). Сервис-ориентированная архитектура - Service-oriented architecture SOA В основе бизнес-архитектуры должна быть процессно-ориентированная модель функций предприятия. Комбинация этого подхода с концепцией сервис-ориентированной архитектуры информационных технологий позволяет лучше увязать процесс разработки компонент информационных систем с миссией, основными задачами и функциями организаций. С помощью SOA организации имеют потенциальную возможность разрабатывать набор реализаций различных бизнес-процессов, которые могут быть многократно использованы предприятием как готовые сервисы. Сервис-ориентированная архитектура - Service-oriented architecture SOA Определения SOA Единого определения SOA, с которым были бы согласны все эксперты, не существует. Различные группы, производители и бизнес-аналитики опубликовали несколько различных определений SOA. Диапазон этих определений включает как высокоуровневое представление о том, что SOA делает для бизнеса, так и определения, концентрирующиеся на технических аспектах решений на базе SOA. Ниже приводится несколько определений, которые можно встретить в специальной литературе, посвященной разработке программного обеспечения. Сервис-ориентированная архитектура - Service-oriented architecture SOA Определение W3C: «Набор вызываемых компонентов, описания интерфейсов которых могут быть опубликованы и обнаружены.» Определение CBDI: «Правила, методы, инфраструктуры, позволяющие предоставлять и потреблять функциональные возможности приложений как наборы сервисов, опубликованных со степенью детализации, значимой для потребителей сервисов, которые могут быть вызваны, опубликованы и обнаружены. Такие наборы сервисов абстрагируются от конкретной реализации при помощи единой, основанной на стандартах формы интерфейса.» Сервис-ориентированная архитектура - Service-oriented architecture SOA Определение Gartner: «Сервис-ориентированная архитектура - это клиент-серверный принцип проектирования программного обеспечения, при котором приложение состоит из программных сервисов и потребителей программных сервисов (также известных как клиенты или запросчики сервисов). Отличие SOA от более общей модели клиент-сервер заключается в явном акценте на слабой связанности между компонентами программного обеспечения и в характерном для нее использовании самых разных интерфейсов.» Сервис-ориентированная архитектура - Service-oriented architecture SOA Определение IBM: Поскольку IBM очень внимательно изучает взаимосвязь между SOA и бизнес-целями и бизнес- задачами предприятия, в Центре компетенции в области SOA в IBM разработали определение SOA, которое учитывает эти аспекты. «Сервис-ориентированная архитектура - это ИТ-архитектура уровня предприятия, предназначенная для установления связи с ресурсами по требованию. Эти ресурсы представлены в виде ориентированных на задачи бизнеса сервисов, которые могут быть включены в пул ресурсов предприятия или направления бизнеса и модифицированы для удовлетворения соответствующих бизнес-потребностей. Первичным структурным элементом приложений SOA является сервис, а не подсистема, система или компонент». Сервис-ориентированная архитектура - Service-oriented architecture SOA В связи с тем, что SOA может быть применима к решению самых разных задач – в зависимости от направления деятельности работающих с этой архитектурой специалистов – были созданы три определения: с точки зрения бизнеса, архитектуры и реализации. Вот эти определения: Определение с точки зрения бизнеса: Набор сервисов, которые бизнес желает предложить своим потребителям и партнерам или другим подразделениям организации. Определение с точки зрения архитектуры: Архитектурный стиль, требующий наличия поставщика и запросчика сервисов, а также описаний сервисов. Набор архитектурных принципов, шаблонов и критериев, учитывающих такие характеристики, как модульность, инкапсулированность, слабая связанность, разделение интересов, многократность использования, компонуемость и единство реализации. Определение с точки зрения реализации: Модель программирования, совместимая со стандартами, инструментами и технологиями Web-сервисов. Сервис-ориентированная архитектура - Service-oriented architecture SOA Под сервис-ориентированной архитектурой понимается подход к проектированию прикладных информационных систем, который руководствуется следующими принципами: явное отделение бизнес-логики прикладной системы от логики презентации информации; реализация бизнес-логики прикладной системы в виде некоторого количества программных модулей (сервисов), которые доступны извне (пользователям и другим модулям), чаще всего в режиме "запрос-ответ", через четко определенные формальные интерфейсы доступа; при этом "потребитель услуги", который может быть прикладной системой или другим сервисом, имеет возможность вызвать сервис через интерфейсы, используя соответствующие коммуникационные механизмы. В целом, SOA представляет собой модель взаимодействия компонент, которая связывает различные функциональные модули приложений (сервисы) между собой с помощью четко определяемых интерфейсов. Сервис-ориентированная архитектура - Service-oriented architecture SOA Как и EA (архитектура предприятия), SOA - это больше, чем архитектура. Кроме архитектурных аспектов, предприятию для полноценного внедрения SOA необходимы механизм управления и план-график перехода. SOA - это не только архитектура Сервис-ориентированная архитектура - Service-oriented architecture SOA SOA состоит из процессов, сервисов и компонентов. Ядром SOA является модель сервиса, которая определяет сервисы и компоненты, с помощью которых они реализуются. На рисунке показан стек SOA-решения и взаимосвязи между элементами, из которых состоит SOA. Стек SOA-решения Сервис-ориентированная архитектура - Service-oriented architecture SOA Данная многоуровневая архитектура показывает, как составные сервисы сопоставляются с бизнес-процессами, и как компоненты масштаба предприятия (грубо детализированные) реализуют сервисы. Бизнес-процессы могут поддерживаться при помощи организации (хореографии) предоставляемых сервисов в составное приложение. Архитектура поддерживается несколькими вертикальными уровнями, включая: Уровень инфраструктуры, который обычно называют сервисной шиной предприятия (Enterprise Service Bus, ESB); Уровень мониторинга и управления, обеспечивающий качество сервиса и удовлетворение нефункциональных требований; Уровень архитектуры данных; Уровень механизма управления. Стек SOA-решения Сервис-ориентированная архитектура - Service-oriented architecture SOA ГЛАВНОЕ 1: Т.к. одним из известных интеграционных шаблонов как раз и является «Сервис», а интерфейсы сами по себе не зависят от используемых аппаратных платформ, операционных систем или языков программирования, используемых для разработки этих приложений. Это позволяет отдельным сервисам взаимодействовать между собой одним и тем же стандартным, но в то же время универсальным способом. Такая особенность использования интерфейса, независимого от окружения и платформы, получила название модели "слабой связи". Ее очевидным преимуществом является повышенная гибкость и адаптируемость, поскольку замена или модернизация одной из компонент системы не сказывается на остальных. Сервис-ориентированная архитектура - Service-oriented architecture SOA ГЛАВНОЕ 2: Принципиальным фактором является то, что современные подходы к реализации SOA охватывают не только технологический уровень обмена данными, но и уровень бизнес-операций. В частности, одним из важных результатов стала разработка специализированного языка BPEL (Business Process Executable Language for Web Services) для описания аспектов взаимодействия различных сервисов с точки зрения реализации бизнес-правил. Вообще говоря, принятие SOA как целевой архитектуры будет подразумевать и соответствующий подход к разработке приложений (SODA – service-oriented development architecture). Сервис-ориентированная архитектура - Service-oriented architecture SOA ТЕНДЕНЦИЯ РАЗВИТИЯ SOA: Предполагается, что в будущем практически все взаимодействие приложений как в рамках одной информационной системы, так и между системами отдельных участников бизнес-процесса, будет осуществляться с использованием технологии web-cервисов, так что достаточно критическими становятся вопросы согласованной работы этих сервисов. Для описания такой работы были предложены даже специальные термины – "хореография" и "оркестровка" (очевидно, по аналогии с управлением оркестром из различных инструментов или ансамблем разных исполнителей). При этом, если хореография определяет взаимодействие различных участников с использованием сервисов, то оркестровка описывает взаимодействие сервисов в рамках одного бизнес-процесса, в частности, с использованием языка типа BPEL. Сервис-ориентированная архитектура - Service-oriented architecture SOA Оркестровка (orchestration) и хореография (choreography) соответствуют двум подходам к описанию бизнес-процессов: в виде последовательности выполнения сервисов или в виде их взаимодействия. Оркестровка - это описание внутреннего бизнес-процесса предприятия в виде потока взаимодействия между внутренними и внешними для организации веб-сервисами. Точка зрения на этот процесс - чисто внутренняя, например, со стороны руководства, или как еще говорят, со стороны владельца бизнес-процесса. Хореография - это определение последовательности условий, при соблюдении которых несколько независимых участников обмениваются сообщениями с целью выполнения некоторой общей бизнес-задачи. Сервис-ориентированная архитектура - Service-oriented architecture SOA Оркестровка относится к исполняемому бизнес-процессу, который может взаимодействовать с внешними и внутренними Web-сервисами. Взаимодействия на основе обмена сообщениями включают в себя бизнес-логику и порядок выполнения задач. Они могут выходить за границы приложений и предприятий, определяя многошаговую транзакционную бизнес-модель. Языками моделирования для описания оркестровки выступают BPEL (Business Process Executive Language) и XPDL (XML Process Definition Language). При этом исполнение орекстровки предполагает наличие центрального процессора, который вызывает веб-сервисы. Веб-сервисы в этом случае "не знают", что они участвуют в более глобальном бизнес-процессе. Соответственно, языками моделирования для описания хореографии выступают WS-CDL (Web-services Choreography Description Language) и ebXML (Electronic Business using eXtensible Markup Language). При хореографии бизнес-процессов не требуется центральный координатор, поскольку каждый веб-сервис "знает", когда выполнять свои операции и с каким другим веб-сервисом он взаимодействует... Сервис-ориентированная архитектура - Service-oriented architecture SOA ВЫВОД: Таким образом, влияние сервис-ориентированных подходов на изменения в архитектуре можно охарактеризовать как сбалансированный переход от централизованной инфраструктуры информационных технологий и замкнутого на себе функционала прикладных систем в сторону архитектуры, обеспечивающей возможности быстрого создания новых систем из набора доступных сервисов, т.е. более гибкой, динамичной и способной к взаимодействию. Ориентация на сервисную архитектуру позволяет построить комплексную ссылочную модель архитектуры предприятия, которая в единой манере описывает как бизнес, так и ИТ. Ссылочная модель сервис-ориентированной архитектуры предприятия Презентационный уровень описывает интерфейсные сервисы для взаимодействия пользователей с информационной системой, включая корпоративные и публичные порталы, доступ с мобильных устройств, а также различные преобразования информации при взаимодействии с внешними системами и устройствами; На уровне бизнес-сервисов формируются модели и осуществляется управление выполнением бизнес-процессов предприятия с использованием специализированных средств (типа BPEL), а также координация автоматизированных и "ручных" операций; Интеграционные сервисы обеспечивают взаимодействие между приложениями, которое может быть реализовано, в частности, с использованием средств обмена сообщениями или в рамках единой среды исполнения, такой как сервер приложений J2EE; Сервисы уровня данных реализуют средства извлечения и повторного использования данных из СУБД и приложений. Явное выделение такого уровня позволяет изолировать вышестоящие компоненты архитектуры от изменений в технологиях (например, смены вендора или версии продукта), а также обеспечить единый унифицированный подход к выполнению операций с данными; Уровень инфраструктуры, приложений и СУБД является как бы основой для всей структуры, и именно здесь концентрируются основные инвестиции в ИТ Ссылочная модель сервис-ориентированной архитектуры предприятия Взаимодействие между этими уровнями, однако, осуществляется не напрямую, а через сервисы, выделенные на уровень обработки событий. Сервисы этой компоненты архитектуры обеспечивают сбор данных о событиях в масштабе всего предприятия, необходимое преобразование и маршрутизацию этих данных между разными уровнями, а также "обратную связь" между сервисами каждого отдельного уровня. Наряду с рассмотренными уровнями, отвечающими за взаимодействие различных групп сервисов "как бы в процессе деятельности предприятия", выделяется отдельная компонента архитектуры, которая описывает аспекты, связанные с жизненным циклом сервисов – то есть их созданием, эксплуатацией и оптимизацией. Архитектура, управляемая моделями (Model-Driven Architecture, MDA) Архитектурная концепция MDA создания информационных систем была предложена консорциумом OMG (Object Management Group, http://www.omg.org), в который сегодня входит более 800 известных производителей программного и аппаратного обеспечения. MDA является определенным обобщением идей SOA, с одной стороны, и повторно используемых программных компонент (шаблонов, паттернов) с другой, предназначенным, прежде всего, для повышения гибкости разрабатываемых приложений масштаба предприятия, чтобы реализовать простоту обеспечения соответствия требованиям бизнеса в условиях изменения используемых инфраструктурных платформ. MDA по определению является открытой и "нейтральной" по отношению к используемым технологиям интеграции. Архитектура, управляемая моделями (Model-Driven Architecture, MDA) MDA основана на следующих принципах: основой для разработки приложений масштаба предприятия являются детальные модели с общепринятой нотацией; построение систем может быть организовано в соответствии с рамочной системой моделей, которые позволяют отделить бизнес-логику приложений от конкретной реализации. Исходной является так называемая независимая модель вычислений (Computational Independent Model, CIM), которая путем последовательных трансформаций через платформо-независимые (PIM) и платформо-специфичные модели (PSM) автоматически или с минимальным участием программиста приводится к исполняемому коду и соответствующим структурам данных; существует формальное описание используемых моделей на основе системы метамоделей (в частности, для таких областей как распределенные вычисления и транзакции, операции в реальном времени и т.п.); принятие и широкое использование этого подхода основано на открытости промышленных стандартов и на поддержке со стороны производителей соответствующих средств разработки. Архитектура, управляемая моделями (Model-Driven Architecture, MDA) В рамках такого подхода сначала создается архитектура, которая описывает модель бизнес-функциональности и поведения прикладной системы независимо от технических деталей реализации. Эта разработка должна вестись в контексте всей корпоративной архитектуры организации. На основе этой модели, не зависящей от платформы реализации, может быть разработана одна или несколько специфических для конкретной платформы моделей, в зависимости от того, какая платформа используется и поддерживается организацией. Уже на основе этих специфических для конкретной платформы моделей разрабатывается код конкретной прикладной системы. |