Информационные структуры предприятия

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

Рубрика Программирование, компьютеры и кибернетика
Вид шпаргалка
Язык русский
Дата добавления 07.06.2017
Размер файла 913,1 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

1. Проблемы при интеграции данных. Конфликты на логическом уровне

Проблемой при интеграции данных является неоднородность источников данных, в соответствии с уровнем интеграции:

— Физический

различные форматы файлов

— Логический

неоднородность используемых моделей данных для различных источников или различаются схемы данных

(одни источники могут быть веб-сайтами, а другие -- базами данных)

— Семантический

различным источникам данных могут соответствовать различные онтологии

Типы несоответствия схем данных

1. Конфликты неоднородности

используются различные модели данных для различных источников

2. Конфликты именования

в различных схемах используется различная терминология

3. Семантические конфликты

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

4. Структурные конфликты

одни и те же сущности представляются в разных источниках разными структурами данных

2. Определение системной интеграции. Цель системной интеграции

Интеграмция (от лат. integratio -- «соединение») -- процесс объединения частей в целое

Интеграция данных -- объединение данных, находящихся в различных источниках и предоставление данных пользователям в унифицированном виде.

Системная интеграция -

-- это разработка комплексных решений по автоматизации технологических и бизнес-процессов предприятия

-- комплексный подход к автоматизации проектирования, производства и создания сетей

-- совокупность торговых операций и проектных работ, имеющих целью создание и эксплуатацию единых многофункциональных информационных систем

-- объединение отдельных компонентов (подсистем) в одну систему и гарантия того, что подсистемы функционируют совместно как единая система

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

Цель системной интеграции

-- максимально эффективное управление технологическими процессами, производством, организацией в целом

3. Структурные и семантические конфликты

Структурные и семантические конфликты

1. Различие в типах данных

Некоторый домен в одном источнике может представляться числом, в другом -- строкой фиксированной длины, в третьем -- строкой переменной длины

2. Различие в единицах измерения

В одной БД указана величина в сантиметрах, в другой -- в дюймах. В этом случае существует отображение 1:1

3. Различие в множестве допустимых значений

Один и тот же признак может определяться разными наборами констант. Например, выполнение задания одним источником может оцениваться по четырехбальной шкале (неудовлетворительно, удовлетворительно, хорошо, отлично), другим -- по трехбальной (-,±,+), третьим -- по стобальной. Отображение не является 1:1, оно может быть многозначным, может не иметь обратного, может зависеть от сторонних данных (например, 30 по математике соответствовать «удовлетворительно», а по русскому языку -- «неудовлетворительно»)

4. Различие «домен-отношение»

Домен в одной БД (например, строковое значение) соответствует таблице в другой БД (записи из таблицы-справочника)

5. Различие «домен -- группа доменов»

В одном источнике адрес записывается одной строкой, в другом -- отдельные поля для улицы, дома, строения, квартиры

6. Различие «данные-схема»

Данные одной БД соответствуют схеме (метаданным) другой. В одной БД «инженер» -- значение атрибута «должность» отношения «работник», в другой «инженеры» -- отношение, содержащее некоторых работников, в то время как «бухгалтеры» содержит других

7. Отсутствующие значения

В каком-то из источников может отсутствовать информация, имеющаяся в большинстве других

4. Понятие системного интегратора. Системная интеграция глазами системных интеграторов

Системный интегратор - принципиальным фактором, отличающим «многопрофильную ИТ-компанию» от «системного интегратора» является наличие в последней высококвалифицированных бизнес-консультантов, способных предложить заказчику комплексное ИТ-решение, направленное на достижение его бизнес-целей, и включающее в себя различные классы взаимосвязанных (интегрированных) систем и решений различных вендоров.

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

-- компания, в стратегии которой преобладает деятельность в сфере системной интеграции

Компании, занимающиеся системной интеграцией, специализируются в создании как систем «под заказ» (custom), так и систем на базе готовых (off-the-shelf) аппаратных, программных и сетевых средств от различных компаний-производителей

Системная интеграция глазами системных интеграторов

— СОЗДАНИЕ комплексных решений в области информационных технологий для корпоративных заказчиков (IBM)

— СОЗДАНИЕ сложных, взаимоувязанных законченных систем функционирования автоматизированных бизнес-процессов предприятия или организации, интегрирующих разнородные технологии и оборудование разных производителей («Ай-Теко»)

— Прежде всего ТВОРЧЕСТВО. Только компания, состоящая из передовых, высокообразованных технически, творческих людей, способных быстро и четко понять потребности заказчика и предложить ему наиболее выгодный вариант решения проблемы, достойна называться интегратором. С точки зрения специалистов, под интеграцией систем понимается проектирование и разработка некой информационной системы, объединяющей в функционально полное решение программные и аппаратные средства, позволяющие заказчику добиться максимально возможного взаимодействия и эффективности различных бизнес-процессов (UAFI-T)

— ВЫБОР экономически оправданного, интегрированного информационно-телекоммуникационного решения для реализации конкретных задач заказчика, его комплексная реализация и сопровождение в течение жизненного цикла системы («Информационная Индустрия»)

— РАБОТЫ по созданию и запуску в эксплуатацию необходимых клиенту систем (ПО или программно аппаратных комплексов), формируемых, как правило, из независимо разработанных компонентов, либо включаемых в состав уже функционирующих систем (ЛАНИТ)

— КОМПЛЕКС РАБОТ, предоставляющих заказчику системные (взаимосвязанные и законченные) решения в части технологий, транспортной среды и оборудования, обеспечивающие эффективный бизнес-процесс оператора («Контур-М»)

— РАЗРАБОТКА специализированных решений, включающих поставку аппаратной платформы и разработку ПО, а также интеграцию разработанного решения с другими бизнес-приложениями заказчика (Siemens)

— ИНТЕГРАЦИЯ различных аппаратных и программных средств в единые подсистемы, а также разработка, производство, монтаж, поддержка и обслуживание программно-аппаратных комплексов, предназначенных для решения определенных заказчиком задач (Computer Mechanics)

— ИСКУССТВО И НАУКА ИНТЕГРАЦИИ процессов, функций, людей и информационных технологий, позволяющей создать IT-систему, удовлетворяющую бизнес-требованиям конкретного предприятия; это умение объединить разрозненные системы заказчика («Энвижн Груп»)

— ДЕЯТЕЛЬНОСТЬ по решению бизнес- и/или технических задач заказчика с привлечением информационных технологий, направленная на повышение эффективности бизнеса заказчика, где результатом является изменение информационной и/или коммуникационной систем заказчика («Открытые Технологии»)

— ОДНО ИЗ НАПРАВЛЕНИЙ, наиболее востребованных в IT-бизнесе, когда интегратор готов взять на себя головную боль заказчика по интеграции в единое целое всех его систем, а также по расширению его сети, т.е. работы, которые из-за нехватки специфических инженерных ресурсов заказчик не в состоянии выполнить своими силами, в необходимые сроки и с гарантированным качеством («Эквант»)

— СПОСОБНОСТЬ обеспечить заказчиков всеми необходимыми механизмами для эффективного управления бизнесом. Сегодня большинство клиентов приходят со своей стратегией и просят помочь ее реализовать. Какими средствами - вопрос вторичный (IBS)

5. Консолидация как архитектура систем интеграции данных

При консолидации данные извлекаются из источников и помещаются в Хранилище данных

— Консолидация -- однонаправленный процесс:

a. данные из нескольких источников сливаются в Хранилище,

b. но не распространяются из него обратно в распределенную систему

Процесс заполнения Хранилища состоит из трех фаз:

a. извлечение,

b. преобразование,

c. загрузка

(Extract, Transformation, Loading -- ETL) Во многих случаях именно ETL понимают под термином «интеграция данных»

Консолидация выполняется с помощью приложений интеграции:

a. как правило, данные извлекаются из источников с определенными интервалами (синхронно)

b. => в хранилище данные попадают с некоторыми временами отставания

1. Результаты системной интеграции

a. Создание единой корпоративной информационной системы

b. Создание единого информационного пространства предприятия

6. Распространение данных как архитектура систем интеграции данных

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

1. Агент обычно работает в оперативном режиме

2. Обновления в системе А могут передаваться в конечную систему B:

a. синхронно

b. асинхронно

3. Синхронная передача требует, чтобы обновления в обеих системах происходили во время одной и той же физической транзакции

4. Распространение данных может быть как односторонним так и двусторонним

5. Репликация данных - частный случай распространения данных

7. Интеграция данных. Уровни интеграции

Интеграция данных включает объединение данных, находящихся в различных источниках, и предоставление данных пользователям в каком-либо унифицированном виде

Уровни интеграции данных

— Физический

сводится к преобразованию данных из различных источников в требуемый единый формат их физического представления

— Логический

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

(Семантические свойства данных при этом не учитываются)

— Семантический

поддержка единого представления данных с учетом их семантических свойств в контексте единой онтологии предметной области

8. Сервисный подход как архитектура систем интеграции данных

Использование сервисно-ориентированной архитектуры SOA (Service Oriented Architecture). Физического перемещения данных не происходит: данные остаются у владельцев и даже местонахождение данных неизвестно. При запросе происходит обращение к определённым сервисам, которые связаны с источниками, где находится информация и ее конкретный адрес

Сервис-ориентированная архитектура

v Сервис-ориентированная архитектура (SOA, англ. service-oriented architecture) -- модульный подход к разработке программного обеспечения, основанный на использовании распределённых, слабо связанных заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам

v Программные комплексы, разработанные в соответствии с сервис-ориентированной архитектурой, обычно реализуются как набор веб-служб, взаимодействующих по протоколу SOAP

· Интеграция данных объединяет информацию из нескольких источников таким образом, чтобы ее можно было показать клиенту в виде сервиса.

· Сервис -- это не запрос в традиционном смысле обращения к данным, скорее, это извлечение некоторой бизнес-сущности (или сущностей), которое может быть выполнено сервисом интеграции через серию запросов и других сервисов

· Сервисы взаимодействуют на основе какого-либо строго определённого платформенно-независимого и языково-независимого интерфейса (например, WSDL). Определение интерфейса скрывает языково-зависимую реализацию сервиса.

9. Типы несоответствия данных. Задача несоответствия данных

Типы несоответствия данных

1. Различие формата данных

«пр. Ленина, 123-1» или «Ленина, д.123, стр.1»; «8(903)123-45-67» или «8-903-123-45-56»

2. Различие в представлении значений

Например, некая организация может быть записана в отдельных источниках как «Томский политехнический университет», «Национальный исследовательский Томский политехнический университет», «ТПУ»

3. Потеря актуальности данных одним из источников

Например, смена должности сотрудника: в одной БД записана новая должность, в другой старая, и они не совпадают.

4. Наличие ошибок операторского ввода (или ошибок распознавания бланков) в отдельных источниках данных

Сюда относятся механические опечатки, ошибки восприятия на слух сложнопроизносимых имен/названий, отсутствие единых стандартов транскрипции с иностранных языков

5. Намеренное внесение искажений с целью затруднить идентификацию сущностей

Например, Ковин и Кoвuн.

Задача несоответствия данных

— Перечисленные различия приводят к дублированию записей при интеграции данных в одну БД. Разрешение перечисленных проблем и устранение дублирования записей вручную практически невозможно. Имеется множество методов для ее автоматического и полуавтоматического решения.

— По-русски задача не имеет устоявшегося термина (применяются «сопоставление записей», «вероятностное соединение», «нестрогое соединение», «нестрогое соответствие»). В зарубежных работах эта задача носит название Identity resolution, или Record linkage (есть и другие синонимы).

10. Паттерны интеграции «Точка - точка» и «Звезда»

Взаимодействие "точка - точка"

— У одной из систем есть интерфейс для доступа к ней активной системы

Взаимодействие "звезда"

Интегрирующая среда:

o имеет универсальный интерфейс для доступа активных систем

o может использовать интерфейсы пассивных систем

включает в себя реализацию основных уровней:

базовый уровень (представляет собой ядро интегрирующей среды). Содержит

a. платформу для исполнения сценариев транзакции

b. базовый функционал по взаимодействию приложений

c. службы протоколирования и мониторинга состояния интегрирующей среды

уровень сценариев интеграции

d. графическая схема обмена сообщениями между системами

e. алгоритмы преобразования и маршрутизации этих сообщений

транспортный уровень интегрирующей среды

f. физическая доставка сообщений между компонентами

уровень адаптеров компонентов

g. взаимодействие с системой посредством ее API

h. генерация сообщений

i. передача сообщений базовому уровню посредством транспортного

11. Федерализация как архитектура систем интеграции данных

При федерализации физического перемещения данных не происходит: данные остаются у владельцев, доступ к ним осуществляется при необходимости (при выполнении запроса)

— Создается общее представление (модель) данных

Медиатор -- посредник, поддерживающий единый пользовательский интерфейс на основе общего представления данных

— Медиатор поддерживает отображения между глобальным и локальным представлениями данных

— Отображение данных из источника в общую модель выполняется при каждом запросе специальной оболочкой (wrapper)

12. Паттерн интеграции «Удалённый вызов процедур»

v приложения интегрированы на уровне функций

v изменение данных в другой системе происходит также посредством вызова функций

Удалённый вызов процедур (от англ. Remote Procedure Call, RPC) -- класс технологий, позволяющих компьютерным программам вызывать функции или процедуры в другом адресном пространстве (как правило, на удалённых компьютерах)

— Обычно реализация RPC технологии включает в себя два компонента:

1. сетевой протокол для обмена в режиме клиент-сервер

2. язык сериализации объектов (или структур, для необъектных RPC).

— Характерные черты вызова удалённых процедур:

1. Асимметричность, то есть одна из взаимодействующих сторон является инициатором

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

— Необходимость сериализации

— Проблемы аварийного завершения

— Проблемы неоднородности языков программирования и операционных сред

13. Направления интеграции

1. Горизонтальная интеграция - интеграция в пределах одного уровня управления

2. Вертикальная интеграция - интеграция между уровнями управления

14. Информационно-управляющая структура производственного предприятия

15. Паттерн интеграции «Файловый обмен»

v системы экспортируют общие данные в формате пригодном для импорта в другие системы

v в качестве единого формата файлов обмена часто выбирают XML

16. Особенности и общая схема SOA

Особенности SOA

— Архитектура не привязана к какой-то определённой технологии. SOA - это не технология, а способ проектирования и организации информационной архитектуры

— SOA может быть реализована с использованием широкого спектра технологий:

— REST, RPC, DCOM, CORBA или веб-сервисы

— Системы, основанные на SOA, могут быть независимы от технологий разработки и платформ

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

— Программные комплексы, разработанные в соответствии с сервис-ориентированной архитектурой, обычно реализуются как набор веб-служб, взаимодействующих по протоколу SOAP (хотя основные положения SOA сложились задолго до появления веб-сервисов)

Общая схема SOA

— SOA предполагает наличие трех основных участников:

1. поставщик сервиса

2. потребитель сервиса

3. реестр сервисов

— Взаимодействие участников выглядит так: поставщик сервиса регистрирует свои сервисы в реестре, а потребитель обращается к реестру с запросом.

17. Паттерн интеграции «Общая база данных»

— приложения работают с едиными данными в любой момент времени

— изменения, произведенные в одном из приложений, автоматически отражаются в другом

— за корректность данных отвечает многопользовательская СУБД

18. Сервисы

Сервисы - основной строительный блок в SOA

Возможные определения:

o повторяющаяся бизнес-задача

o независимый программный модуль с возможностью самоописания

o доступный ресурс, выполняющий повторяющееся действие и описанный с помощью открытой спецификации

19. Паттерн интеграции «Интеграция систем по данным»

· подход характерен для традиционных систем «клиент-сервер»

· концепция интеграции состоит в том, что приложения объединяются в систему вокруг интегрированных данных под управлением СУБД

· интегрирующей средой является промышленная СУБД (как правило, реляционная) со стандартным интерфейсом доступа к данным (обычно это доступ на SQL). Все функции прикладной обработки размещаются в клиентских программах

20. Сервисная шина

Сервисная шина предприятия - (англ. enterprise servicebus, ESB) -- связующее программное обеспечение, обеспечивающее централизованный и унифицированный событийно-ориентированный обмен сообщениями между различными информационными системами на принципах сервис-ориентированной архитектуры

Основной принцип сервисной шины -- концентрация обмена сообщениями между различными системами в единой точке

ESB обеспечивает унифицированное взаимодействие между службами, созданными в различных средах

Сервисная шина обеспечивает:

— транзакционный контроль

— преобразование данных

— сохранность сообщений

— централизация настройки обработки и передачи данных

21. Паттерн интеграции «Функционально-центрический подход»

· концепция интеграции состоит в том, что приложения объединяются в систему вокруг интегрированных сервисов со стандартизованным интерфейсом. Интегрирующей средой является сервер приложений или монитор транзакций со стандартным API.

· приложение декомпозируется на три уровня (взаимодействие с пользователем, прикладная обработка, доступ к данным).

· общая архитектура системы является трехзвенной: клиентское приложение - функциональные сервисы - сервер базы данных.

22. Координация процессов. Преобразование и маршрутизация сообщений

интегратор архитектура система данные

Координация процессов

· Позволяет комбинировать несколько сервисов для реализации бизнес-процесса

· Реализуется с помощью языка BPEL

· Для выполнения бизнес-процесса, описанного на BPEL, применяется специальное ПО - среда исполнения процессов

Преобразование и маршрутизация сообщений

· Сервисная шина отвечает за выполнение следующих задач интеграции:

a. Преобразование протоколов

b. Преобразование форматов сообщений

c. Сопоставление сообщений

d. Маршрутизация сообщений

e. Обеспечение безопасности, журналирование, поддержка транзакций

23. Паттерн интеграции «Обмен сообщениями»

· основан на асинхронном обмене сообщениям посредством шины данных

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

· интеграционная шина отвечает за логику интеграции

· подход позволяет легко интегрировать новые системы, а также изменять логику интеграции, легко приводя ее в соответствие с бизнес логикой процесса

24. Стандарт OPC

· OPC (OLE for Process Control) -- семейство программных технологий, предоставляющих единый интерфейс для управления объектами автоматизации и технологическими процессами

· Создание и поддержку спецификаций OPC координирует международная некоммерческая организация OPC Foundation, созданная в 1994 году ведущими производителями средств промышленной автоматизации

· Стандарт OPC разрабатывался с целью сократить затраты на создание и сопровождение приложений промышленной автоматизации:

a. разработчикам промышленных программ предоставляется универсальный фиксированный интерфейс (то есть набор функций) обмена данными с любыми устройствами

b. разработчики устройств предоставляют программу, реализующую этот интерфейс (набор функций)

25. Паттерн интеграции «Объектно-центрический подход»

1. концепция интеграции в состоит в том, что системы объединяются вокруг общедоступных распределенных объектов со стандартными интерфейсами

2. Характерными особенностями являются

a. унифицированный язык спецификации интерфейсов объектов (например IDL)

b. отделение реализации компонентов от спецификации их интерфейсов

c. общий механизм поддержки взаимодействия объектов (брокер объектных запросов, играющий роль "общей шины", поддерживающей взаимодействие объектов).

3. Интегрирующей средой является брокер объектных запросов с интерфейсом в стандарте CORBA или DCOM.

4. Общая архитектура системы формируется на основе распределенных объектов и является n-звенной

26. OPC DA и OPC UA

OPC DA 2.05

1. V2.05 - наиболее широко используемая

2. В этом стандарте помимо синхронного обмена данными, введена поддержка асинхронного обмена данными

3. Асинхронный обмен данных позволяет продолжать выполнение программы без ожидания ответа устройства:

a. снижает нагрузку на сеть, должен быть рекомендован как основной

b. получение данных реализуется с помощью callback-функции пользовательской программы, которая вызывается в момент прихода ответа от устройства

OPC DA

Существует 4 стандартных режима чтения данных из ОРС сервера:

— синхронный режим: клиент посылает запрос серверу и ждет от него ответ

— асинхронный режим: клиент отправляет запрос и сразу же переходит к выполнению других задач. Сервер после выполнения функции запроса посылает клиенту уведомление и тот забирает предоставленные данные

— режим подписки: клиент сообщает серверу список тегов, значения которых сервер должен отправлять клиенту только в случае их изменения.

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

В каждом из этих режимов данные могут читаться:

— непосредственно из физического устройства

— из кэша ОРС сервера

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

Данные состоят из трех полей:

— значение

— качество

— временная метка

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

Запись данных в физическое устройство может быть выполнена только двумя методами:

1) синхронным

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

2) асинхронным

o клиент отправляет данные серверу и сразу продолжает свою работу. После окончания записи сервер отправляет клиенту соответствующее уведомление

ь выполняется сразу в устройство, без промежуточной буферизации

Клиентская программа и ОРС сервер могут быть установлены:

— на одном и том же компьютере

— на разных компьютерах сети Ethernet

ь Это достигается благодаря технологии DCOM, использующей удаленный вызов процедур (RPC - Remote Procedure Call)

Из операционных систем технологию COM/DCOM поддерживают следующие:

— ОС Windows, начиная с Windows 95 (с установленным компонентом DCOM) и до Windows 2000. Начиная с Windows XP модель DCOM поддерживается только для целей обеспечения совместимости

— большинство Unix-подобных ОС, включая Linux; поддерживается фирмой GE Software

— ОС реального времени QNX; мост OPC реализуется при помощи решения OPC DataHub компании Cogent

— ОС реального времени VxWorks; обеспечивается фирмой-разработчиком WindRiver; имеется поддержка OPC, встроенная в систему разработки Tornado

OPC UA

OPC Unified Architecture

— отказ от использования COM-интерфейса, обеспечивается кросс-платформенная совместимость

— новый стандарт уже изначально позволяет обеспечить более высокий уровень безопасности данных, чем OPC DA

— новая спецификация дает возможность организации передачи информации через сеть интернет.

27. Понятие сервис-ориентированной архитектуры

Компоненты сервис-ориентированной архитектуры

1. Сервисы

2. Сервисная шина

3. Координация процессов

4. Преобразование и маршрутизация сообщений

5. Реестр сервисов

Сервисы - основной строительный блок в SOA

Возможные определения:

1. повторяющаяся бизнес-задача

2. независимый программный модуль с возможностью самоописания

3. доступный ресурс, выполняющий повторяющееся действие и описанный с помощью открытой спецификации

Сервисная шина предприятия - (англ. enterprise servicebus, ESB) -- связующее программное обеспечение, обеспечивающее централизованный и унифицированный событийно-ориентированный обмен сообщениями между различными информационными системами на принципах сервис-ориентированной архитектуры

Координация процессов

— Позволяет комбинировать несколько сервисов для реализации бизнес-процесса

— Реализуется с помощью языка BPEL

— Для выполнения бизнес-процесса, описанного на BPEL, применяется специальное ПО - среда исполнения процессов

Преобразование и маршрутизация сообщений

Сервисная шина отвечает за выполнение следующих задач интеграции:

— Преобразование протоколов

— Преобразование форматов сообщений

— Сопоставление сообщений

— Маршрутизация сообщений

— Обеспечение безопасности, журналирование, поддержка транзакций

Реестр сервисов

Центральное хранилище, необходимое для регистрации и управления сервисами

Может использоваться для хранения:

1. описания интерфейсов сервисов (на WSDL)

2. метаданных сервисов

Пример спецификации реестра - стандарт UDDI

— … для описания интерфейсов сервисов:

o поиска сервиса

o публикации сервиса

o управления сервисами

o подписки на сервисы

· … для метаданных сервисов:

o провайдер сервиса

o доступность

o время, в которое сервис доступен для использования

o характеристики производительности и показатели производительности

28. Формат JSON. Преимущества и недостатки

JSON (англ. JavaScript Object Notation) -- текстовый формат обмена данными, основанный на JavaScript

— Несмотря на происхождение от JavaScript, формат считается независимым от языка и может использоваться практически с любым языком программирования

— Легко читается людьми

— Легко генерируется и обрабатывается программами

— По сравнению с XML более компактен

JSON-текст представляет собой (в закодированном виде) одну из двух структур:

1. Набор пар ключ: значение

В различных языках это реализовано как объект, запись, структура, словарь, хэш-таблица, список с ключом или ассоциативный массив. Ключом может быть только строка, значением -- любая форма.

2. Упорядоченный набор значений

Во многих языках это реализовано как массив, вектор, список или последовательность

В качестве значений в JSON используются структуры:

Объект -- это неупорядоченное множество пар ключ:значение, заключённое в фигурные скобки «{ }». Ключ описывается строкой, между ним и значением стоит символ «:». Пары ключ-значение отделяются друг от друга запятыми.

Массив (одномерный) -- это упорядоченное множество значений. Массив заключается в квадратные скобки «[ ]». Значения разделяются запятыми.

Значение может быть строкой в двойных кавычках, числом, объектом, массивом, одним из литералов: true, false или null. Т.о. структуры могут быть вложены друг в друга.

Строка -- это упорядоченное множество из нуля или более символов юникода, заключенное в двойные кавычки. Символы могут быть указаны с использованием escape-последовательностей, начинающихся с обратной косой черты «\». Строка очень похожа на одноимённый тип данных в языках С и Java. Число тоже очень похоже на С- или Java-число, за исключением того, что используется только десятичный формат. Пробелы могут быть вставлены между любыми двумя синтаксическими элементами.

Преимущества и недостатки

Преимущества

— Компактный формат данных для обмена данными между приложениями

— Очень хорошее средство поддержки (почти каждый язык программирования поддерживает JSON)

— Меньше накладных расходов во время разбора и сериализации чем XML

Недостатки

— Не легко для прочтения человеком

— Работает только c кодировкой UTF-8

29. Реестр сервисов

Центральное хранилище, необходимое для регистрации и управления сервисами

Может использоваться для хранения:

1. описания интерфейсов сервисов (на WSDL)

2. метаданных сервисов

Пример спецификации реестра - стандарт UDDI

— … для описания интерфейсов сервисов:

o поиска сервиса

o публикации сервиса

o управления сервисами

o подписки на сервисы

· … для метаданных сервисов:

o провайдер сервиса

o доступность

o время, в которое сервис доступен для использования

o характеристики производительности и показатели производительности

Размещено на Allbest.ru

...

Подобные документы

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

    реферат [1,3 M], добавлен 25.03.2013

  • Архитектура и технология функционирования системы. Извлечение, преобразование и загрузка данных. Oracle Database для реализации хранилища данных. Создание структуры хранилища. Механизм работы системы с точки зрения пользователя и с точки зрения платформы.

    курсовая работа [2,2 M], добавлен 22.02.2013

  • Изучение общих понятий теории систем и системного анализа. Методика построения объектных репозиториев открытых информационных систем. Принципы восприятия визуальной информации. Средства визуального моделирования рабочих процессов по интеграции данных.

    курсовая работа [195,1 K], добавлен 04.06.2015

  • Общее понятие и признаки классификации информационных систем. Типы архитектур построения информационных систем. Основные компоненты и свойства базы данных. Основные отличия файловых систем и систем баз данных. Архитектура клиент-сервер и ее пользователи.

    презентация [203,1 K], добавлен 22.01.2016

  • Архитектура предприятия как инструмент управления изменениями. Проектирование архитектуры данных по TOGAF. Описание потоков и источников данных. Синхронизация данных по времени. Описание этапов и рекомендации по использованию инструментов проектирования.

    дипломная работа [2,8 M], добавлен 09.09.2017

  • Тенденция развития систем управления базами данных. Иерархические и сетевые модели СУБД. Основные требования к распределенной базе данных. Обработка распределенных запросов, межоперабельность. Технология тиражирования данных и многозвенная архитектура.

    реферат [118,3 K], добавлен 29.11.2010

  • Сущность, понятие баз данных. Краткая характеристика MS Access. Обеспечение сохраняемости объектов. Архитектура Object Data Management Group. Объектные расширения реляционных СУБД. Концептуальные особенности систем управления активными базами данных.

    курсовая работа [48,1 K], добавлен 17.05.2013

  • Основные понятия базы данных. Разработка сложной формы для обработки данных. Модели организации данных. Архитектура Microsoft Access. Реляционные связи между таблицами баз данных. Проектирование базы данных. Модификация данных с помощью запросов действий.

    лабораторная работа [345,5 K], добавлен 20.12.2011

  • Уровневая архитектура компьютерных ресурсов CMS. Поток данных от детекторов для анализа. Сокращение размера событий: CMS форматы данных и форматы Тир-данных. Иерархия CMS данных. Средства удаленной работы на LINUX машинах в CERN: PUTTY, WinSCP и Xming.

    курсовая работа [3,1 M], добавлен 17.02.2014

  • Небезопасность и ненадежность интернета вещей. Специфика медицинских систем мониторинга в сетях IOT. Высокоуровневая архитектура системы Medicus. Детали реализации обработки внешних данных. Безопасность IOT устройств. Меры защиты персональных данных.

    курсовая работа [2,4 M], добавлен 24.07.2016

  • Описание нетрадиционных и мультипроцессорных архитектур вычислительных систем. Принципы параллельной и конвейерной обработки данных. Теория массового обслуживания и управления ресурсами компьютерных систем. Базовые топологии локальных и глобальной сетей.

    книга [4,2 M], добавлен 11.11.2010

  • Понятие и классификация систем передачи данных. Характеристика беспроводных систем передачи данных. Особенности проводных систем передачи данных: оптико-волоконных и волоконно-коаксиальных систем, витой пары, проводов. Оценка производителей аппаратуры.

    курсовая работа [993,0 K], добавлен 04.03.2010

  • Теоретические аспекты СУБД. Основные понятия. Функциональные возможности СУБД. Архитектура систем управления. Разработка базы данных. Крупные массивы данных размещают, как правило, отдельно от исполняемого программы, и организуют в виде базы данных.

    курсовая работа [30,5 K], добавлен 23.02.2006

  • Определение, свойства и характеристики распределенных систем баз данных. Основная задача систем управления ими. Архитектура распределения СУБД. Сравнение технологий файлового сервера и "клиент-сервера". Стратегия распределения данных по узлам сети ЭВМ.

    курсовая работа [601,3 K], добавлен 24.05.2015

  • Понятие базы данных, ее архитектура. Классификация баз данных. Основные модели данных. Примеры структурированных и неструктурированных данных. Достоинства и недостатки архитектуры файл-сервер. Иерархическая модель данных. Виды индексов, нормализация.

    презентация [1,4 M], добавлен 06.08.2014

  • Характеристика процесса консолидации данных в Excel. Консолидация данных по физическому расположению; по заголовкам строк и столбцов; с использованием ссылок. Создание сводной таблицы на основе данных, находящихся в нескольких диапазонах консолидации.

    реферат [4,9 M], добавлен 13.01.2011

  • Изучение функций автоматизированных банков данных. Общие принципы описания, хранения и манипулирования данными. Анализ требований к базам данных. Файл-серверная и клиент-серверная архитектура БД. Преимущества введения системы управления базами данных.

    презентация [91,5 K], добавлен 13.08.2013

  • Построение банков данных. Инструментальные средства баз данных Borland. Принцип работы и архитектура баз данных в Delphi. Навигационный способ доступа к базам данных: операции с таблицей, сортировка и перемещение по набору данных, фильтрация записей.

    курсовая работа [642,7 K], добавлен 06.02.2014

  • Архитектура "клиент-сервер". Параллельная обработка данных в многопроцессорных системах. Модернизация устаревших информационных систем. Характерные черты современных серверных СУБД. Наиболее популярные серверные СУБД. Распределенные запросы и транзакции.

    курсовая работа [309,2 K], добавлен 11.11.2011

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

    дипломная работа [1,0 M], добавлен 18.11.2017

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.