Автор: Пользователь скрыл имя, 18 Марта 2012 в 19:38, реферат
Совершенствование многих решений в области информационной поддержки бизнеса идет рука об руку с развитием самой области высоких технологий. Уже давно бизнес не просто использует достижения IT, но и во многом определяет направление развития этой индустрии. Возможность быстрой обработки огромных массивов данных и доступность информации являются важнейшими факторами, определившими стремление бизнеса освоить новые технологии,
Содержание:
1. Введение ……………………………………………………………………………………..3
2. Взаимодействие подсистем………………………………………………………………….4
3. Основные стандарты поддержки промежуточного программного слоя OMG OMA.….5
4. Технология CORBA…………………………………………………………………………5
5. Object Management Architecture……………………………………………………………..8
6. Object Request Broker…………………………………………………………………….….8
7. Microsoft DCOM/COM+…………………………………………………………………….11
8. OLE……………………………………………………………………………………….…..13
9. Интеграция в Web……………………………………………………………………………18
10. XML…………………………………………………………………………………….…….18
11. Web сервисы…………………………………………………………………………………..19
12. Web – система хранения данных……………………………………………………………20
13. Классификация технологий интеграции ………………………………………………….22
14. Microsoft.NET как платформа интеграции…
Важнейшим свойством ACL является включение в нее метаданных - описаний данных. Это позволит программисту легко получить список реквизитов кредитного договора, их названий и типов.
В Web-системе метаданные охватывают все объекты системы, в ACL реализованы классы, позволяющие легко манипулировать ими.
Это дает возможность разработки не только статических страниц, и не только страниц запрашивающих фиксированный набор параметров у пользователя и выдающих фиксированную таблицу с данными, как это обычно делается в Интернет-приложениях и клиент-серверных системах.
Классы метаданных библиотеки ACL позволяют создавать динамические интеллектуальные страницы.
В результате имеется иерархический набор параметров, которые нужно запросить у пользователя. Взаимодействие страницы с ACL происходит на транспорте XML. Т.е страница и ACL обмениваются вопросами и ответами в виде XML-документов.
3. Слой доступа. Существуют возможности доступа к бизнес-объектам для платформ Windows NT(IIS) и UNIX(Apache и т.д.):
Вариант 1. Передача запроса к Хранилищу и получение из него данных с помощью COM-объекта с достаточно простым интерфейсом. В этот объект как XML-документ передается запрос и из него извлекается код возврата, сообщение и результат запроса.
Вариант 2. Использование в качестве скриптового языка- Python , который очень для этого удобен. Кроме того именно на Python реализована библиотека ACL и программист получает непосредственный доступ к ее объектам.
Вариант 3. Применение специально разработанного Java-скрипт для передачи XML-запросов к библиотеке ACL и получения от нее XML-ответов.
4. Слой транспорта. Запросы к Хранилищу, полученные данные и служебная информация перемещается между слоем интерфейса и слоем доступа в виде XML-документов.
5. Слой интерфейса. Интерфейс создается дизайнером сайта как совокупность страниц, обращающихся к объектам на языке XML. При этом доступны все данные Хранилища, но не требуется знание его физической структуры. Никакое изменение структуры данных не приводит к необходимости изучения новых схем таблиц, или изменения существующих страниц, за счет изоляции базы данных при помощи библиотеки XML.
В результате создания Web-системы хранения данных организация может быстро и эффективно организовать на своем сайте доступ к данным корпоративного хранилища.
Открытость и многослойность архитектуры позволяет применить любые стандартные и уникальные технологии защиты информации от создания закрытых Интранет сетей, до применения шифрации и электронных подписей при обмене данными с клиентами.
Классификация технологий интеграции
На уровне отдельной организации проблема интеграции возникает сразу, как только в ней внедряется несколько корпоративных приложений. Можно дать следующую классификацию технологий интеграции:
1) Системы интеграции корпоративных приложений (Enterprise Applications Integration, EAI) — технологии, ориентированные на решение проблем интеграции различных систем, приложений и данных внутри отдельной организации. Иногда для этих технологий используется аббревиатура A2A (Application-to-Application — приложение-приложение).
2) Системы интеграции между организациями Business-to-Business (Business-to-Business Integration, B2Bi) — технологии, ориентированные на обеспечение безопасного, надежного информационного обмена между различными организациями и их информационными системами. Эти технологии обеспечивают пересылку информации за пределы сетевых экранов (firewall) и дают возможность автоматизировать бизнес-процессы в рамках «расширенных организаций», которые включают поставщиков, партнеров, потребителей продуктов и услуг и т. д.
3) Технологии управления бизнес-процессами (Business Process Management, BPM), являющиеся результатом естественной эволюции классических систем документооборота и делопроизводства (workflow systems) и систем класса EAI и B2Bi. Традиционные системы управления документами ориентировались в основном на пересылку информации между людьми, выполнявшими определенные действия. В отличие от технологий B2Bi, которые ориентированы на интеграцию данных в межведомственной среде, технологии BPM интегрируют данные, приложения и людей через единые бизнес-процессы. Это отражает современную точку зрения, что основой интеграции должны быть бизнес-процессы. Причина здесь состоит в том, что бизнес-процессы организации «пересекают» границы различных приложений, департаментов и организаций.
Следующая таблица показывает разницу между упомянутыми классами систем.
Технология | Кто принимает решение об использовании | Решаемая проблема |
---|---|---|
Workflow | Руководитель департамента, отдела | Управление документами и пересылка документов |
EAI и B2Bi | Руководитель департамента информационных технологий | Интеграция данных |
BPM | Высшее руководство организации (бизнес-руководство) | Улучшение выполнения бизнес-процессов и повышение эффективности работы за счет большей гибкости процессов |
Традиционные технологии интеграции корпоративных приложений EAI и межворганизационной интеграции B2Bi основаны на использовании так называемого брокера (узла пересылки, шлюза) сообщений. Технологическим фундаментом брокера сообщений является, как правило, программное обеспечение промежуточного слоя пересылки сообщений (Messaging-Oriented Middleware, MOM), которое обеспечивает транспорт доставки информации и данных между прикладными системами. Примером такого программного обеспечения является «сервер очередей сообщений» MSMQ (Microsoft Message Queuing). Продукты этого класса обеспечивают транспорт гарантированной доставки сообщений между приложениями в территориально распределенной среде. Подход к интеграции приложений на основе продуктов класса MOM стал стандартным в области интеграции корпоративных информационных систем в конце 90-х годов.
Базовая идея этой технологии заключается в следующем. Пусть имеется несколько приложений, связанных некоторой коммуникационной средой, но, возможно, не очень надежной. Одно приложение (например, система документооборота A) должно переслать информацию/документ другому приложению (системе документооборота B). Система A передает документ серверу пересылки сообщений и «забывает» о нем. Сервер пересылки сообщений обеспечит гарантированную и однократную доставку информации в систему B.
Если при этом интегрируемые приложения находятся внутри организации в рамках одной корпоративной сети, то обеспечивается пересылка информации в режиме, «близком к реальному времени».
Если интегрируются приложения, находящиеся в разных организациях, то принцип «очереди сообщений» и гарантированной доставки, который реализуется MOM-продуктами, обеспечивает асинхронное взаимодействие и так называемое «слабое связывание» . Приложение организации A не вправе ожидать мгновенной доступности приложения организации B, но программное обеспечение гарантированной доставки сообщений берет на себя ответственность за доставку информации между ними.
Компоненты брокера сообщений
Сегодня брокеры сообщений могут объединять большое количество взаимодействующих систем. Результатом этого является так называемая «Корпоративная нервная система», т.е. инфраструктура брокера сообщений, к которой легко могут быть подключены по сути дела любые приложения и которая обеспечивает взаимодействие между ними в режиме, близком к реальному времени.
Рисунок - Брокер сообщений
Брокер сообщений интегрирует гетерогенные приложения и хранилища данных и предоставляет три типа служб:
1) Пересылка сообщений и перемещение данных обеспечивает физический транспорт доставки сообщений между приложениями. Это может быть сделано на основе таких Интернет-протоколов, как Hypertext Transfer Protocol (HTTP) и традиционных систем пересылки сообщений, например Microsoft Messaging Queuing и IBM MQ Series. Первые поколения этих технологий использовали собственные закрытые форматы для своих сообщений. В последнее время языком описания сообщений все больше становится XML.
2) Интеллектуальная маршрутизация, которая определяет для каждого сообщения то, к какому приложению оно должно попасть. Маршрутизация часто включает механизмы публикации и подписки, когда серверное приложение один раз «публикует» некоторое бизнес-событие для брокера сообщений, а определенное количество других бизнес-приложений, заинтересованных в данном событии, «подписываются» на него.
3) Трансформирование обеспечивает мапирование (определение соответствия) данных между потенциально различными семантиками одного приложения или разных приложений. Так, если одно приложение использует в формате своих данных буквы «М» и «Ж» для описания пола человека, а другое приложение использует для такого кодирования «1» и «0», то уровень трансформации брокера сообщений может мапировать информацию между приложениями, не меняя логику каждого из них. В более сложных ситуациях, когда одно приложение может ожидать 5 атрибутов в записи о клиенте, а другое приложение обеспечивает эти же атрибуты в двух различных записях баз данных, уровень трансформации может обеспечить мапирование между такими различными структурами данных.
Архитектура брокера сообщений может включать две дополнительных высокоуровневых службы:
1) Управление бизнес-процессами (оркестрирование бизнес-процессов) доводит уровень интеллектуальной маршрутизации до возможностей автоматизации потоков работ (workflow), которые полностью обслуживают внутренние и внешние процессы;
2) Мониторинг процессов и событий превращает брокер сообщений в центр информационных потоков внутри и вне предприятия, а также обеспечивает функции анализа бизнес-операций в масштабе близком к реальному времени.
Помимо этого, брокеры сообщений, как правило, поддерживают работу со специфическими адаптерами для различных типов приложений и данных:
- адаптеры к веб-службам;
- адаптеры к мониторам транзакций;
- адаптеры к различным реляционным СУБД;
- API-адаптеры для популярных коробочных приложений.
Наличие указанных дополнительных высокоуровневых служб, а также средств для моделирования процессов (графических средств описания и модификации процессов), по сути дела, превращает системы EAI и B2Bi в системы класса BPM (системы управления бизнес-процессами).
Сервер Microsoft BizTalk Server представляет собой именно такую систему управления бизнес-процессами (BPM), которая обеспечивает широкий набор средств для определения сложных бизнес-процессов, в которых могут участвовать внешние организации.
Microsoft BizTalk Server включает в себя:
- графические средства определения сложных, распределенных и долго протекающих (часы, дни, недели) бизнес-процессов. Эти средства имеют возможность разделения логики бизнес-процессов и физической реализации;
- средства визуального определения структурированных бизнес-документов;
- средства мапирования (определения соответствия) между различными форматами бизнес-документов, включая возможности задания правил трансформации;
- средства управления (консоль) для определения организаций, вовлеченных в бизнес-процесс, и средства определения правил взаимодействия и обработки сообщений;
- средства анализа, отслеживания и хранения документов для последующего анализа;
- средства мониторинга и управления работой интеграционного шлюза.
Базовые принципы интеграции с использованием XML и веб-служб
Рассмотрим базовые принципы интеграции ПО с использованием XML и веб-служб на примере государственной межведомственной интеграции.
Итак, основой межведомственной интеграции может служить интеграционное программное обеспечение и системы управления бизнес-процессами (BPM), такие как, например, Microsoft BizTalk Server. При этом XML претендует на роль универсального формата данных при такой интеграции. А сами ведомственные системы, как вновь разрабатываемые, так и унаследованные, могут быть реализованы в виде так называемых веб-служб или могут сделать свои интерфейсы доступными в виде веб-служб.
Рисунок - Гипотетическая система выдачи водительских прав, использующая XML
Чтобы прояснить суть этих подходов к организации межведомственного взаимодействия и интеграции информационных систем, рассмотрим простые базовые понятия, связанные со стандартами XML и веб-службами. Первое и главное, что следует отметить, — это то, что все описываемые ниже стандарты являются открытыми, а в их разработке принимают участие такие ведущие ИТ-компании, как Microsoft и IBM, а также органы стандартизации Интернет-сообщества в лице консорциума World Wide Web Consortium (W3C) и организации UDDI.org. Это имеет особую важность, поскольку государство должно ориентироваться на открытые стандарты интеграции.
Второе. Данные технологии не зависят от платформы и не требуют от организаций, чьи приложения интегрируются, использовать такие общие платформенные продукты, как операционные системы и СУБД.
По своей сути XML — это мета-язык для представления данных. Термин «мета» используется потому, что XML-документ не только содержит в себе данные, но также несет информацию, описывающую эти данные. XML является такой же универсальной и базовой технологией для представления, трансформации и обмена данными, как транспортный протокол Transmission Control Protocol/Internet Protocol (TCP/IP) для Интернета.
XML предоставляет общий формат для пересылки данных между приложениями. При этом сами данные могут по-прежнему храниться в прикладных системах и базах данных в своем внутреннем формате, но в случае необходимости их пересылки в другое приложение они будут трансформироваться в формат XML, как в промежуточный формат, понимаемый всеми системами. Уже сегодня стандарт XML поддерживается поставщиками основных платформенных программных продуктов.