ЛЕКЦИЯ 6. ЭЛЕМЕНТЫ ТЕХНОЛОГИЧЕСКОЙ АРХИТЕКТУРА АРХИТЕКТУРА ИНФОРМАЦИОННЫХ СИСТЕМ. - презентация

1 ЛЕКЦИЯ 6. ЭЛЕМЕНТЫ ТЕХНОЛОГИЧЕСКОЙ АРХИТЕКТУРА АРХИТЕКТУРА ИНФОРМАЦИОННЫХ СИСТЕМ

2 РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА Б. Я. Советов, А. И. Водяхо, В. А. Дубенецкий, В. В. Цехановский. Архитектура информационных систем: учебник для студ. учреждений высш. проф. образования. - М. : Издательский центр «Академия», А.В. Данилин, А.И. Слюсаренко. Архитектура предприятия. М: ИНТУИТ,

3 АРХИТЕКТУРА ИНФОРМАЦИОННОЙ СИСТЕМЫ Бизнес- архитектура ИТ-архитектура Архитектура данных Архитектура приложений Технологическая архитектура

4 ТЕХНОЛОГИЧЕСКАЯ АРХИТЕКТУРА Данная область архитектуры рассматривает "традиционные" аспекты построения информационных систем, которые необходимы для поддержки прикладных систем и информационных ресурсов организации. Для описания технологической архитектуры используются такие термины, как " платформа ", " инфраструктура ", " системная архитектура " или просто "ИТ-архитектура".

5 НАЗНАЧЕНИЕ ТЕХНОЛОГИЧЕСКОЙ АРХИТЕКТУРЫ Основное назначение технологической архитектуры –обеспечение надежных ИТ-сервисов, предоставляемых в рамках всего предприятия в целом и координируемых централизованно. Технологическая архитектура определяет набор принципов и стандартов, которые обеспечивают руководства в отношении выбора и использования таких технологий как: аппаратные платформы, операционные системы, системы управления базами данных, средства разработки, языки программирования, ПО промежуточного слоя, сервисы электронной почты, служба каталоги, системы безопасности, сетевая инфраструктура и т.д.

6 МОДЕЛИ, ИСПОЛЬЗУЕМЫЕ ДЛЯ РАЗЛИЧНЫХ ПРЕДСТАВЛЕНИЙ (ДОМЕНОВ) И ПЕРСПЕКТИВ (УРОВНЕЙ АБСТРАКЦИИ) Домены/перспективы (уровни абстракции)Технологическая архитектура Контекст ("планировщик") Список мест расположения бизнеса Концептуальный уровень("владелец" предприятия) Модели бизнес-логистики Операционные (нефункциональные) требования Архитектура расположения элементов центра обработки данных Логический ("проектировщик") Логические типы серверов: БД, почтовые, транзакционные, … Географическое распределение серверов Хостируемое ПО Физический ("разработчик") Физические серверы Топология фрагментов сети Мапирование продуктов на сервисы и приложения

7 РАЗЛИЧНЫЕ УРОВНИ РАЗМЕЩЕНИЯ ИНФРАСТРУКТУРЫ

8 КОМПОНЕНТЫ ТЕХНОЛОГИЧЕСКОЙ АРХИТЕКТУРЫ Методология Gartner называет в технологической архитектуре шесть архитектурных компонент (сервисов), в каждом из которых выделяется определенное количество технологических блоков: Сервисы данных Прикладные сервисы Программное обеспечение промежуточного слоя (middleware) Вычислительная инфраструктура Сетевые сервисы Сервисы безопасности

9 СЕРВИСЫ ДАННЫХ Примеры : системы управления базами данных (технологии баз данных и методы доступа к базам), хранилища данных (хранилища и витрины данных), системы поддержки принятия решений (Business Intelligence – средства анализа и средства подготовки отчетов).

10 ПРИКЛАДНЫЕ СЕРВИСЫ Примеры: языки программирования (языки для программирования серверной части, языки для программирования клиентской части, интегрированные среды), средства разработки приложений (средства моделирования баз данных, репозитории, методики разработки приложений, средства обеспечения качества), системы коллективной работы (средства групповой работы и электронной почты, средства управления документами), архитектура приложений (модель компонент, серверы приложений, серверы поддержки тонких клиентов), геоинформационные системы и средства

11 ВЫЧИСЛИТЕЛЬНАЯ ИНФРАСТРУКТУРА Примеры: операционные системы и аппаратное обеспечение (приложения для настольных систем, операционные системы для настольных систем, мобильные устройства – ноутбуки, беспроводные устройства, персональные цифровые помощники, серверы приложений/данных, сетевые операционные системы, принтеры), среда для web-инфраструктуры (браузеры, web-порталы, web- серверы, средства управления и создания контента, серверы каталогов, форматы публикации информации), системы хранения (Storage Area Network – сети хранения данных, накопители на магнитных лентах, накопители на оптических дисках и CD, системы хранения высокой надежности RAID), средства системного управления (средства сетевого управления, администрирование IP), топологии (топология распределенных приложений)

12 СЕТЕВЫЕ СЕРВИСЫ Примеры: локальные сети (протоколы, кабельные системы, топология), глобальные сети (транспорт, протоколы), технологии доступа (пользователи с удаленным доступом, эмуляция терминалов и шлюзы, беспроводные технологии для локальных и глобальных сетей, интегрированные средства передачи данных и голоса, обеспечение доступности, средства видеоконференций), голосовые технологии (голос/данные поверх IP-протокола, голосовая почта), сетевое аппаратное обеспечение (концентраторы, маршрутизаторы и пр.).

13 СЕРВИСЫ БЕЗОПАСНОСТИ Примеры: авторизация, аутентификация (внутренняя и внешняя аутентификация, PKI), сетевая безопасность (Network Firewall, Internet Firewall), физическая безопасность центров обработки данных, прочие сервисы безопасности (обнаружение вторжений, защита от вирусов).

14 ВЗАИМОСВЯЗИ ФУНКЦИОНАЛЬНЫХ И ОПЕРАЦИОННЫХ ТРЕБОВАНИЙ С АРХИТЕКТУРОЙ ПРИЛОЖЕНИЙ И ТЕХНОЛОГИЧЕСКОЙ АРХИТЕКТУРОЙ

15 ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ Функциональные требования к прикладной системе описывают ту ценность, которую представляет система с точки зрения реализации функций организации (бизнес-ценность). Архитектура приложений является архитектурой всех автоматизированных сервисов, которые обеспечивают и реализуют такие функциональные требования, включая интерфейсы к бизнес- приложениям и другим прикладным системам. Она описывает структуру приложений и то, как эта структура реализует функциональные требования организации.

16 ОПЕРАЦИОННЫЕ ТРЕБОВАНИЯ Операционные (или эксплуатационные) требования к программной системе специфицируют такие аспекты, как надежность, управляемость, производительность, безопасность, совместимость и т.д. Примерами операционных требований являются возможность доступа к системе только авторизованных пользователей, уровень доступности прикладной системы 99,99% времени и т.д.

17 ОЦЕНКА СОСТОЯНИЯ ТЕХНОЛОГИЧЕСКОЙ ИНФРАСТРУКТУРЫ Оценка состояния технологической инфраструктуры предприятия на основе подхода, предложенного Питером Кином (Peter Keen), основана на критериях: Функциональные возможности: возможности по выполнению бизнес- активностей, начиная с простых, таких как пересылка информации (сообщений), до выполнения сложных транзакций, которые могут производиться совместно сотрудниками, а также поставщиками и клиентами; Охват: физические места расположения и группы людей, которые инфраструктура способна объединить, начиная от отдельного подразделения и до уровня отдельного сотрудника, где бы он ни находился.

18 МАТРИЦА ОЦЕНКИ

19 АДАПТИВНАЯ ТЕХНОЛОГИЧЕСКАЯ ИНФРАСТРУКТУРА Основными характеристиками адаптивной системы являются: само конфигурирование – организация системы в соответствии с требованиями; самозащита – предотвращение сбоев в системе в результате нарушения работы компонент системы и потери целостности данных; самовосстановление – диагностика неисправностей, локализация ошибок и устранение их последствий; самооптимизация – наиболее рациональное использование имеющихся ресурсов без вмешательства оператора.

20 НЕОБХОДИМОСТЬ ПОВЫШЕНИЯ ЭФФЕКТИВНОСТИ ИСПОЛЬЗОВАНИЯ ВЫЧИСЛИТЕЛЬНЫХ РЕСУРСОВ Проблема – типовая загрузка мейнфреймов составляла порядка 80%, В настоящее время характерными значениями являются порядка 40% для RISC-серверов и всего лишь 15% для Intel/Windows серверов. Это является следствием достаточно распространенной практики "каждому приложению – свой сервер".

21 КОНЦЕПЦИЯ "ИНФРАСТРУКТУРА РЕАЛЬНОГО ВРЕМЕНИ" КОНЦЕПЦИЯ "ИНФРАСТРУКТУРА РЕАЛЬНОГО ВРЕМЕНИ" Концепция "Инфраструктура реального времени" (Real-Time Infrastructure, RTI) была предложена Gartner. Инфраструктура реального времени RTI представляет собой "разделяемую между участниками, бизнес- подразделениями или приложениями инфраструктуру информационных систем, в которой бизнес-политики и соглашения об уровнях услуг (SLA) определяют ее динамическую и адаптивную оптимизацию для сокращения затрат при увеличении гибкости и качества сервиса".

22 АДАПТИВНАЯ ИНФРАСТРУКТУРА Основные идеи адаптивной инфраструктуры: все ИТ-ресурсы являются общими и разделяемыми; выделение ресурсов конкретным приложениям производится автоматически в соответствии с требованиями бизнеса; качество обслуживания является предсказуемым и стабильным, несмотря на непредсказуемый спрос на ресурсы.

23 ИНФРАСТРУКТУРА РЕАЛЬНОГО ВРЕМЕНИ

24 РОЛЬ СТАНДАРТОВ Стандарты обеспечивают возможность взаимодействия различных компонент между собой. Различают стандарты де-юре, т.е. разработанные и поддерживаемые официальными органами по стандартизации, такими как Международная организация по стандартизации – ISO, и стандарты де-факто, основанные на существующем широком распространении технологии, методологии или продукта (например, использование MS Windows в качестве операционной системы для персональных компьютеров).

25 ТЕХНОЛОГИЧЕСКИЕ СТАНДАРТЫ Технологические стандарты определяют особенности реализации тех или иных протоколов, интерфейсов, языков программирования и т.п. Типичным примером являются спецификации WWW консорциума W3C.

26 РАМОЧНЫЕ СТАНДАРТЫ Рамочные стандарты (Framework) задают общие требования к реализации процессов, связанных с разработкой и поддержкой жизненного цикла систем. Они используются как методологическая основа для организации этих процессов с необходимой конкретизацией для каждого данного предприятия или области деятельности. Примеры ISO требования к стандартным архитектурам и методологиям предприятия ISO определяет жизненный цикл системы в целом ISO для определения жизненного цикла программного обеспечения

27 ИСПОЛЬЗОВАНИЕ АРХИТЕКТУРНЫХ ШАБЛОНОВ Реализация поддержки бизнес-процесса в информационной системе может использовать уже известные фрагменты программного кода и/или типовые конфигурации оборудования. Это позволяет: значительно сократить сроки выполнения решения, уменьшить риски за счет использования фрагментов, проверенных на практике. Речь идет о выборе и использовании подходящих шаблонов (patterns).

28 ПРИМЕНЕНИЕ ШАБЛОНОВ Общее решение - означает, что шаблон не дает полного законченного решения. Шаблон определяет класс проблемы и то, как эта проблема может быть решена с использованием определенного подхода, с демонстрацией аргументов в пользу этого подхода. Сила шаблона состоит в том, что он сформулирован на достаточно высоком уровне абстракции, чтобы быть использованным в большом количестве ситуаций; Повторяющаяся проблема – означает, что шаблоны используются в тех случаях, когда проблема не является уникальной, и они наиболее полезны для решения часто встречающихся проблем; Определенный контекст – означает, что шаблон обеспечивает решение проблемы, границы которой в общих чертах определены. Понимая условия, в которых предлагаемое решение в форме шаблона является хорошим, строится свое собственное решение на основе этого шаблона.

29 ПРИМЕР ШАБЛОНА

30 ИСПОЛЬЗОВАНИЕ ШАБЛОНОВ

31 СЕРВИС-ОРИЕНТИРОВАННАЯ АРХИТЕКТУРА Под сервис-ориентированной архитектурой понимается подход к проектированию прикладных информационных систем, который руководствуется следующими принципами: явное отделение бизнес-логики прикладной системы от логики презентации информации; реализация бизнес-логики прикладной системы в виде некоторого количества программных модулей (сервисов), которые доступны извне (пользователям и другим модулям), чаще всего в режиме "запрос-ответ", через четко определенные формальные интерфейсы доступа; "потребитель услуги" (может быть прикладной системой или другим сервисом) имеет возможность вызвать сервис через интерфейсы, используя соответствующие коммуникационные механизмы.

32 ПРИМЕРЫ ИСПОЛЬЗОВАНИЯ SOA Для задач электронного бизнеса соответствующая функциональность SOA реализуется на уровне web- сервисов (служб). Под web-сервисами понимаются программные системы, которые используют: XML в качестве формата данных, стандарты Web Services Description Language (WSDL) для описания своих интерфейсов, Simple Object Access Protocol (SOAP) для описания формата принимаемых и посылаемых сообщений стандарт Universal Description, Discovery and Integration (UDDI) для создания каталогов доступных сервисов.

33 ССЫЛОЧНАЯ МОДЕЛЬ СЕРВИС- ОРИЕНТИРОВАННОЙ АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ

34 АРХИТЕКТУРА, УПРАВЛЯЕМАЯ МОДЕЛЯМИ (MDA) Концепция MDA была предложена консорциумом OMG (Object Management Group, в который сегодня входит более 800 известных производителей программного и аппаратного обеспечения. MDA является определенным обобщением идей SOA и повторно используемых программных компонент (шаблонов, паттернов). MDA предназначена для повышения гибкости разрабатываемых приложений масштаба предприятия, чтобы обеспечить простоту обеспечения соответствия требованиям бизнеса в условиях изменения используемых инфраструктурных платформ.

35 ПРИНЦИПЫ MDA основой для разработки приложений масштаба предприятия являются детальные модели с общепринятой нотацией; построение систем может быть организовано в соответствии с рамочной системой моделей, которые позволяют отделить бизнес-логику приложений от конкретной реализации. Исходной является так называемая независимая модель вычислений (Computational Independent Model), которая путем последовательных трансформаций через платформо-независимые (PIM) и платформо-специфичные модели (PSM) автоматически или с минимальным участием программиста приводится к исполняемому коду и соответствующим структурам данных; существует формальное описание используемых моделей на основе системы метамоделей (в частности, для таких областей как распределенные вычисления и транзакции, операции в реальном времени и т.п.); принятие и широкое использование этого подхода основано на открытости промышленных стандартов и на поддержке со стороны производителей соответствующих средств разработки.

36 СОЗДАНИЕ ПРИКЛАДНЫХ СИСТЕМ В СООТВЕТСТВИИ С ПОДХОДОМ MDA