Реферат: Корпоративные сети

• Неоднородность, распределенность и автономность информационных ресурсов системы. Неоднородность ресурсов может быть синтаксической (при их представлении используются, например, разные модели данных) и/или семантической (используются разные виды семантических правил, детализируются и/или агрегируются разные аспекты предметной области). Возможна и чисто реализационная неоднородность информационных ресурсов, обусловленная использованием разных компьютерных платформ, операционных систем, систем управления базами данных, систем программирования и т.д.).
• Потребности в интеграционном комплексировании компонентов информационной системы. Очевидно, что наиболее естественным способом организации сложной информационной системы является ее иерархически-вложенное построение. Более сложные фун- кционально-ориентированные компоненты строятся на основе более простых компонентов, которые могли проектироваться и разрабатываться независимо (что порождает неоднородность; ниже мы приведем примеры).
• Реинжинерия системы. После создания начального варианта информационной системы неизбежно последует процесс ее непрерывных переделок (реинжинерии), обусловленный развитием и изменением соответствующих бизнес-процессов корпорации. Реконструкция системы не должна быть революционной. Все компоненты, не затрагиваемые процессом реинжиниринга, должны сохранять работоспособность.
• Решение проблемы унаследованных (legacy) систем. Любая компьютерная система (на- деюсь, что это не относится к открытым системам в теперешнем понимании; только надеюсь, поскольку неизвестно, как отнесутся к нашим взглядам будущие поколения) со временем становится бременем корпорации. Постоянно (и чем раньше, тем лучше) приходится решать задачу встраивания устаревших информационных компонентов в систему, основанную на новой технологии. Нужно, чтобы эта задача была разрешимой, т.е. чтобы компоненты унаследованных систем сохраняли интероперабельность.
• Повторно используемые (reusable) ресурсы. Технология разработки информационных систем должна способствовать использованию уже существующих компонентов, что в конечном итоге должно перевести нас от экстенсивного ручного программистского труда к интенсивным методам сборки ориентированной на конкретную область применения информационной системы.
• Продление жизненного цикла информационной системы. Чем дольше живет и приносит пользу информационная система, тем это выгоднее для корпорации. Естественно, что для этого должна существовать возможность добавления в нее компонентов, спроектированных и разработанных, вообще говоря, в другой технологии.

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

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

При строгой интеграции неоднородных БД локальные системы БД утрачивают свою автономность. После включения локальной БД в федеративную систему все дальнейшие действия с ней, включая администрирование, должны вестись на глобальном уровне. Поскольку пользователи часто не соглашаются утрачивать локальную автономность, желая тем не менее иметь возможность работать со всеми локальными СУБД на одном языке и формулировать запросы с одновременным указанием разных локальных БД, то развивается направление мульти-БД. В системах мульти-БД не поддерживается глобальная схема интегрированной БД и применяются специальные способы именования для доступа к объектам локальных БД. Как правило, в таких системах на глобальном уровне допускается только выборка данных. Это позволяет сохранить автономность локальных БД.

Как правило, интегрировать приходится неоднородные БД, распределенные в вычислительной сети. Это в значительной степени усложняет реализацию. Дополнительно к собственным проблемам интеграции приходится решать все проблемы, присущие распределенным СУБД: управление глобальными транзакциями, сетевую оптимизацию запросов и т.д. Очень трудно добиться эффективности. Как правило, для внешнего представления интегрированных и мульти-БД используется (иногда расширенная) реляционная модель данных. В последнее время все чаще предлагается использовать объектно-ориентированные модели, но на практике пока основой является реляционная модель. Поэтому, в частности, включение в интегрированную систему локальной реляционной СУБД существенно проще и эффективнее, чем включение СУБД, основанной на другой модели данных.

Основным недостатком систем интеграции неоднородных баз данных является то, что при этом не учитываются "поведенческие" аспекты компонентов прикладной системы. Легко заметить, что даже при наличии развитой интеграционной системы, большинство из указанных выше проблем не решается. Естественным развитием взглядов на информационные ресурсы является их представление в виде набора типизированных объектов, сочетающих возможности сохранения информации (своего состояния) и обработки этой информации (за счет наличия хорошо определенного множества методов, применимых к объекту). Наиболее существенный вклад в создание соответствующей технологии внес международный консорциум OMG, выпустивший ряд документов, в которых специфицируются архитектура и инструментальные средства поддержки распределенных информационных систем, интегрированных на основе общего объектно-ориентированного подхода.

В базовом документе специфицируется эталонная модель архитектуры (OMA - ObjectManagementArchitecture) распределенной информационной системы (рисунок 9.9). Согласованная с архитектурой OMA прикладная информационная система представляется как совокупность классов и экземпляров объектов, которые взаимодействуют при поддержке брокера объектных заявок (ORB - ObjectRequestBroker). ORB, общие средства (CommonFacilities) и объектные службы (ObjectServices) относятся к категории промежуточного программного обеспечения (middleware) и должны поставляться вместе. Объектные службы представляют собой набор услуг (интерфейсов и объектов), которые обеспечивают выполнение базовых функций, требуемых для реализации прикладных объектов и объектов категории "общие средства" (например, специфицированы служба именования объектов, служба долговременного хранения объектов, служба управления транзакциями и т.д.). Общие средства содержат набор классов и экземпляров объектов, поддерживающих функции, полезные в разных прикладных областях (например, средства поддержки пользовательского интерфейса, средства управления информацией и т.д.).

Рис. 9.9. Эталонная модель OMA

В основе OMA лежит базовая объектная модель COM (CoreObjectModel), в которой специфицированы такие понятия, как объект, операция, тип, подтипизация, наследование, интерфейс. Определены также способы согласованного расширения COM в разных объектных службах.

Интерфейсы объекта-клиента и объекта-сервера должны быть определены на специальном языке IDL (InterfaceDefinitionLanguage), который очень напоминает компонент спецификации класса (без реализации) языка Си++. Обращения к ORB могут быть сгенерированы статически при компиляции спецификаций IDL или выполнены динамически с использованием специфицированного в документах OMGAPI брокера объектных заявок. Правила построения и использования ORB определены в документе OMGCORBA (CommonObjectRequestBrokerArchitecture).

Заметим, что архитектура, предложенная OMG, не является единственно возможной. В частности, альтернативные (и очень популярные) решения предлагает компания Microsoft со своей моделью SOM и продуктами OLE, ActiveX, OLEDB.

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

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

9.4. Проблемы проектирования и разработки приложений

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

9.4.1. Как правильно оценить текущие и будущие потребности организации

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

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52