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

9.4).

[pic]

Рис. 9.4. Информационная система в архитектуре "клиент-сервер" с выделенным

сервером приложений

Информационные системы в трехзвенном (или многозвенном исполнении) могут

создаваться на основе использования промежуточного программного обеспечения

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

Inc. или Encina компании TransarcCorp.

Громадным преимуществом клиент-серверной архитектуры любого рода является

ее масштабируемость и вообще способность к развитию. При проектировании

информационной системы, основанной на этой архитектуре, большее внимание

следует обращать на грамотность общих решений. Технические средства

пилотной версии могут быть минимальными (например, в качестве аппаратной

основы сервера баз данных может использоваться одна из рабочих станций).

После создания пилотной версии нужно провести дополнительную

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

этого необходимо принимать решение о выборе аппаратуры сервера, которая

будет использоваться на практике.

Увеличение масштабов информационной системы не порождает принципиальных

проблем. Обычным решением является замена аппаратуры сервера (и, может

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

кэшированию баз данных). В любом случае практически не затрагивается

прикладная часть информационной системы. В идеале, которого конечно же не

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

после смены аппаратуры.

9.3.2. Влияние intranet-технологии

В предыдущих разделах курса уже говорилось довольно много о технологии

Internet/Intranet. В этом пункте мы сосредоточимся на возможных

архитектурных решениях Intranet-систем.

Возникновение и внедрение в широкую практику высокоуровневых служб

Всемирной Сети Сетей Internet (e-mail, ftp, telnet, Gopher, WWW и т.д.)

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

информационных систем, породив направление, известное теперь под названием

Intranet. По сути дела, информационная Intranet-система - это корпоративная

система, в которой используются методы и средства Internet. Такая система

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

опираться на виртуальную корпоративную подсеть Internet. В последнем случае

особенно важны средства защиты информации от несанкционированного доступа.

Хотя в общем случае в Intranet-системе могут использоваться все возможные

службы Internet, наибольшее внимание привлекает гипермедийная служба WWW

(WorldWideWeb - Всемирная Паутина). Видимо, для этого имеются две основные

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

документов HTML можно сравнительно просто разработать удобную для

использования информационную структуру, которая в дальнейшем будет

обслуживаться одним из готовых Web-серверов. Во-вторых, наличие нескольких

готовых к использованию клиентских частей - браузеров, или "обходчиков",

избавляет от необходимости создавать собственные интерфейсы с

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

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

системы (рисунок 9.5) оказывается достаточной для удовлетворения

потребностей компании.

[pic]

Рис. 9.5. Простая организация Intranet-системы с использованием средств WWW

Однако при всех своих преимуществах (простота организации, удобство

использования, стандартность интерфейсов и т.д.) эта схема обладает

сильными ограничениями. Прежде всего, как видно из рисунка 9.5, в

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

может пользователь, это только просмотреть информацию, поддерживаемую Web-

сервером. Далее, гипертекстовые структуры трудно модифицируются. Для того,

чтобы изменить наполнение Web-сервера, необходимо приостановить работу

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

нормальное функционирование. Наконец, далеко не всегда достаточен поиск

информации в стиле просмотра гипертекста. Базы данных и соответствующие

средства выборки данных по-прежнему часто необходимы.

На самом деле, все перечисленные трудности могут быть разрешены с

использованием более развитых механизмов Web-технологии. Эти механизмы

непрерывно совершенствуются, что одновременно и хорошо и плохо. Хорошо,

потому что появляются новые возможности. Плохо, потому что отсутствует

стандартизация.

Что касается логики приложения, то при применении Web-технологии существует

возможность ее реализации на стороне Web-сервера. Для этого могут

использоваться два подхода - CGI (CommonGatewayInterface) и API

(ApplicationProgrammingInterface). Оба подхода основываются на наличии в

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

следует послать Web-серверу специальное сообщение, при получении которого

сервер должен вызвать соответствующую внешнюю процедуру, получить ее

результаты и вернуть их клиенту в стандартном формате HTTP (рисунок 9.6).

[pic]

Рис. 9.6. Вызов внешней процедуры Web-сервера

Заметим, что подход CGI является более надежным (внешняя программа

выполняется в отдельном адресном пространстве), но менее эффективным, чем

подход API (в этом случае внешние процедуры компонуются совместно со

стандартной частью Web-сервера).

[pic]

Рис. 9.7. Доступ к базе данных в Intranet-системе

Аналогичная техника широко используется для обеспечения унифицированного

доступа к базам данных в Intranet-системах. Язык HTML позволяет вставлять в

гипертекстовые документы формы. Когда браузер натыкается на форму, он

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

содержащее введенные параметры. Как правило, к форме приписывается

некоторая внешняя процедура сервера. При получении сообщения от клиента

сервер вызывает эту внешнюю процедуру с передачей параметров пользователя.

Понятно, что такая внешняя процедура может, в частности, играть роль шлюза

между Web-сервером и сервером баз данных. В этом случае параметры должны

специфицировать запрос пользователя к базе данных. В результате получается

конфигурация информационной системы, схематически изображенная на рисунке

9.7.

На принципах использования внешних процедур основывается также возможность

модификации документов, поддерживаемых Web-сервером, а также создание

временных "виртуальных" HTML-страниц.

Даже начальное введение в Intranet было бы неполным, если не упомянуть про

возможности языка Java. Java - это интерпретируемый объектно-

ориентированный язык программирования, созданный на основе языка Си++ с

удалением из него таких "опасных" средств как адресная арифметика.

Мобильные коды (апплеты), полученные в результате компиляции Java-

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

поступают на сторону клиента вместе с документом и выполняются либо

автоматически, либо по явному указанию. Апплет может быть, в частности,

специализирован как шлюз к серверу баз данных (или к какому-либо другому

серверу). При применении подобной техники доступа к базам данных схема

организации Intranet-системы становится такой как на рисунок 9.8.

[pic]

Рис. 9.8. Доступ к базе данных на стороне клиента Intranet-системы

На наш взгляд, Intranet является удобным и мощным средством разработки и

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

относительным недостатком подхода можно считать постоянное изменение

механизмов и естественное отсутствие стандартов. С другой стороны, если

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

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

будет обязан что-либо менять в системе по причине появления более

совершенных механизмов.

9.3.3. Особенности архитектур приложений, ориентированных на оперативную

аналитическую обработку

Специфика архитектур приложений, ориентированных на оперативную

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

хранилищ информации - складов данных (datawarehouse) и рынков данных

(datamarts). Мы кратко обсудили возможные архитектурные решения и не будем

больше возвращаться к этому вопросу (хотя упомянуть его нужно было

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

информационных систем).

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

приложений

Нет никаких проблем, если с самого начала информационное приложение

проектируется и разрабатывается в духе подхода открытых систем: все

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

системы не зависит от конкретного местоположения компонентов, система

обладает хорошими возможностями сопровождаемости и развития. К сожалению,

на практике этот идеал является трудно достижимым. По разным причинам (мы

перечислим некоторые из них ниже) возникают потребности в интеграции

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

ресурсов. Видимо, ни в одной действительно серьезной распределенной

информационной системе не удастся обойтись без применения некоторой

технологии интеграции. К счастью, теперь существует путь решения этой

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

крупнейшим международным консорциумом OMG (ObjectManagementGroup).

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

интеграции разнородных информационных ресурсов:

. Неоднородность, распределенность и автономность информационных

ресурсов системы. Неоднородность ресурсов может быть синтаксической

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

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

детализируются и/или агрегируются разные аспекты предметной области).

Возможна и чисто реализационная неоднородность информационных

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

операционных систем, систем управления базами данных, систем

программирования и т.д.).

. Потребности в интеграционном комплексировании компонентов

информационной системы. Очевидно, что наиболее естественным способом

организации сложной информационной системы является ее иерархически-

вложенное построение. Более сложные фун- кционально-ориентированные

компоненты строятся на основе более простых компонентов, которые могли

проектироваться и разрабатываться независимо (что порождает

неоднородность; ниже мы приведем примеры).

. Реинжинерия системы. После создания начального варианта информационной

системы неизбежно последует процесс ее непрерывных переделок

(реинжинерии), обусловленный развитием и изменением соответствующих

бизнес-процессов корпорации. Реконструкция системы не должна быть

революционной. Все компоненты, не затрагиваемые процессом

реинжиниринга, должны сохранять работоспособность.

. Решение проблемы унаследованных (legacy) систем. Любая компьютерная

система (на- деюсь, что это не относится к открытым системам в

теперешнем понимании; только надеюсь, поскольку неизвестно, как

отнесутся к нашим взглядам будущие поколения) со временем становится

бременем корпорации. Постоянно (и чем раньше, тем лучше) приходится

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

систему, основанную на новой технологии. Нужно, чтобы эта задача была

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

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

. Повторно используемые (reusable) ресурсы. Технология разработки

информационных систем должна способствовать использованию уже

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

экстенсивного ручного программистского труда к интенсивным методам

сборки ориентированной на конкретную область применения информационной

системы.

. Продление жизненного цикла информационной системы. Чем дольше живет и

приносит пользу информационная система, тем это выгоднее для

корпорации. Естественно, что для этого должна существовать возможность

добавления в нее компонентов, спроектированных и разработанных, вообще

говоря, в другой технологии.

Решение проблемы интеграции неоднородных информационных ресурсов началось с

попыток интеграции неоднородных баз данных. Направление интегрированных или

федеративных систем неоднородных БД и мульти-БД появилось в связи с

необходимостью комплексирования систем БД, основанных на разных моделях

данных и управляемых разными СУБД.

Основной задачей интеграции неоднородных БД является предоставление

пользователям интегрированной системы глобальной схемы БД, представленной в

некоторой модели данных, и автоматическое преобразование операторов

манипулирования БД глобального уровня в операторы, понятные соответствующим

локальным СУБД. В теоретическом плане проблемы преобразования решены,

имеются реализации.

При строгой интеграции неоднородных БД локальные системы БД утрачивают свою

автономность. После включения локальной БД в федеративную систему все

дальнейшие действия с ней, включая администрирование, должны вестись на

глобальном уровне. Поскольку пользователи часто не соглашаются утрачивать

локальную автономность, желая тем не менее иметь возможность работать со

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

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

мульти-БД. В системах мульти-БД не поддерживается глобальная схема

интегрированной БД и применяются специальные способы именования для доступа

к объектам локальных БД. Как правило, в таких системах на глобальном уровне

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

локальных БД.

Как правило, интегрировать приходится неоднородные БД, распределенные в

вычислительной сети. Это в значительной степени усложняет реализацию.

Дополнительно к собственным проблемам интеграции приходится решать все

проблемы, присущие распределенным СУБД: управление глобальными

транзакциями, сетевую оптимизацию запросов и т.д. Очень трудно добиться

эффективности. Как правило, для внешнего представления интегрированных и

мульти-БД используется (иногда расширенная) реляционная модель данных. В

последнее время все чаще предлагается использовать объектно-ориентированные

модели, но на практике пока основой является реляционная модель. Поэтому, в

частности, включение в интегрированную систему локальной реляционной СУБД

существенно проще и эффективнее, чем включение СУБД, основанной на другой

модели данных.

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

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

системы. Легко заметить, что даже при наличии развитой интеграционной

системы, большинство из указанных выше проблем не решается. Естественным

развитием взглядов на информационные ресурсы является их представление в

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

информации (своего состояния) и обработки этой информации (за счет наличия

хорошо определенного множества методов, применимых к объекту). Наиболее

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

консорциум OMG, выпустивший ряд документов, в которых специфицируются

архитектура и инструментальные средства поддержки распределенных

информационных систем, интегрированных на основе общего объектно-

ориентированного подхода.

В базовом документе специфицируется эталонная модель архитектуры (OMA -

ObjectManagementArchitecture) распределенной информационной системы

(рисунок 9.9). Согласованная с архитектурой OMA прикладная информационная

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

которые взаимодействуют при поддержке брокера объектных заявок (ORB -

ObjectRequestBroker). ORB, общие средства (CommonFacilities) и объектные

службы (ObjectServices) относятся к категории промежуточного программного

обеспечения (middleware) и должны поставляться вместе. Объектные службы

представляют собой набор услуг (интерфейсов и объектов), которые

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

прикладных объектов и объектов категории "общие средства" (например,

специфицированы служба именования объектов, служба долговременного хранения

объектов, служба управления транзакциями и т.д.). Общие средства содержат

набор классов и экземпляров объектов, поддерживающих функции, полезные в

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

интерфейса, средства управления информацией и т.д.).

[pic]

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

В основе OMA лежит базовая объектная модель COM (CoreObjectModel), в

которой специфицированы такие понятия, как объект, операция, тип,

подтипизация, наследование, интерфейс. Определены также способы

согласованного расширения COM в разных объектных службах.

Интерфейсы объекта-клиента и объекта-сервера должны быть определены на

специальном языке IDL (InterfaceDefinitionLanguage), который очень

напоминает компонент спецификации класса (без реализации) языка Си++.

Обращения к ORB могут быть сгенерированы статически при компиляции

спецификаций IDL или выполнены динамически с использованием

специфицированного в документах OMGAPI брокера объектных заявок. Правила

построения и использования ORB определены в документе OMGCORBA

(CommonObjectRequestBrokerArchitecture).

Заметим, что архитектура, предложенная OMG, не является единственно

возможной. В частности, альтернативные (и очень популярные) решения

предлагает компания Microsoft со своей моделью SOM и продуктами OLE,

ActiveX, OLEDB.

Основным выводом из материала этого пункта является то, что проблемы

Страницы: 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