Перспективы построения глобальной инфраструктуры объектной интеграции систем, дополняющей SOA в части управления данными |
Владимир Овчинников
© Fusionsoft
Аудитория: IT-разработчики и CIO, сообщество IT-специалистов
Оглавление:
Введение
Масштабируемость единого пространства объектов
Типизация объектов
Безопасность пространства объектов
Транзакции в пространстве объектов

Текущий уровень развития IT-технологий позволяет делать многое: комплексные системы, взаимодействующие друг с другом на основе открытых стандартов. IT-индустрия проделала большой путь за последние один-два десятилетия. Но информационное пространство в Сети по-прежнему остается лоскутным. Существует развитый инструментарий представления информации человеку посредством единственной программы - WEB-браузера, но Вы понимаете, что это не содержательная интеграция (интеграция на уровне информации), а пока только организация доступа к системам через одно окно. Отсутствие содержательной интеграции проявляется хотя бы в том, что, подключившись к одной системе и получив из нее данные, пользователь не свободен в поиске взаимосвязанных данных в смежной системе, если соответствующая функциональность не заложена производителями обеих систем изначально.
Если сказать, что IT-сообщество ничего не делает для преодоления этой проблемы - то это не будет соответствовать действительности. Делается очень многое - разрабатываются как общие стандарты взаимодействия систем (например, SOA), так и частные стандарты, соблюдение которых гарантирует содержательную интеграцию систем в конкретных предметных областях. Но текущий уровень усилий в этом направлении оставляет ощущение недостаточности: разработка стандартов ведется с трудом, во-первых, из-за большого количества заинтересованных сторон, а, во-вторых, из-за достаточно высокой сложности технологий интеграции систем.
В связи с этим встает вопрос - можно ли упростить технологическую составляющую этого процесса, разработав некую единую инфраструктуру содержательной интеграции систем? Конечно, вы ответите мне, что она уже существует - это SOA. SOA действительно может использоваться для качественной интеграции ряда систем в рамках единого программного интерфейса, но эффективное решение этой задачи возможно только при использовании открытых стандартов соответствующей предметной области, которые далеко не всегда существуют. Если же стандартов нет, то каждому производителю систем приходится полагаться на собственные решения. В результате мы получаем совокупность разрозненных систем, взаимодействие между которыми должно разрабатываться отдельно для каждой пары из них.
SOA позволяет осуществлять интеграцию систем, но не всегда это можно сделать достаточно просто и масштабируемо. Реальное упрощение процесса интеграции систем может быть достигнуто лишь тогда, когда системы, подлежащие интеграции, начнут работать в едином пространстве объектов - с общим механизмом доступа и ссылок на объекты. Только в этом случае границы между системами могут быть стерты - они начнут работать с общими данными без необходимости отдельной разработки модулей взаимодействия смежных систем. Единое пространство объектов (данных) способно дать значительное упрощение процесса интеграции систем. В результате фактически формируется единая метасистема, состоящая из ряда интегрированных систем.
Очевидно, что данный подход, ориентированный на данные, и SOA, ориентированная на поведение, не противоречат, но дополняют друг друга. Единое пространство объектов позволяет поднять интеграцию систем по данным на новый технологический уровень, так как система поддержки этого пространства может взять на себя всю специфику по работе с данными, предоставив унифицированный интерфейс по работе с объектами. Расширение такого пространства объектов может осуществляться гибко и прозрачно для существующих систем, без необходимости в реализации каких-либо сложных интеграционных проектов в рамках существующих систем. По этим же причинам каждый сервис, построенный в рамках SOA, выиграет от работы с данным пространством объектов - сервисы смогут использовать общие данные без ограничений.
Подход построения единого пространства объектов не нов. Именно он используется в решениях, основанных на интеграции ряда реляционных схем в одну. В этом случае разработчик пользовательского интерфейса получает в свои руки интегрированную схему, основываясь на которой он может достаточно просто строить бесшовные пользовательские интерфейсы и другую обработку данных. Но масштабирование таких решений ограничено рамками одной организации или холдингом. Невозможно увеличивать количество систем, охваченных одной интегрированной схемой, до бесконечности. Рано или поздно это приведет к деградации производительности всей интегрированной системы. Мы же здесь говорим о едином пространстве объектов с неограниченной масштабируемостью, чтобы в рамках него можно было опубликовать любое количество объектов и систем.
Конечно, масштабы задач, которые нужно решить для построения единого глобального пространства объектов вызывают сомнения в их принципиальной осуществимости. Во-первых, еще необходимо доказать, что такое пространство можно построить технически. Интуитивно кажется совершенно очевидным, что это невозможно. Во-вторых, организационная составляющая такого проекта просто безгранична - для того, чтобы такая система заработала, ее должны поддерживать многие поставщики информации, что составляет огромный объем усилий со стороны всего IT-сообщества.
Необходимо сразу отметить, что рассуждения о едином пространстве объектов, приведенные здесь, не являются чисто теоретическими. Изложенные далее идеи были проверены и легли в основу продукта EntryService ООО "Фьюжнсофт", который Вы можете получить здесь: http://www.fusionsoft-online.com/entryservice.php.
Сначала вкратце рассмотрим основные сомнения, которые возникают, когда мы начинаем говорить о едином пространстве объектов в глобальном масштабе. Первое сомнение - как обеспечить достаточную масштабируемость для такого пространства, ведь количество объектов будет столь огромным, что сейчас его сложно даже оценить? Не потеряет ли это пространство всякую практическую ценность в результате деградации при расширении? Детально развеять данное сомнение мы сможем только в ходе более детального изложения ниже. Здесь мы можем привести краткий ответ - иерархическая организация объектов и систем, подобно X.500/LDAP и DNS, предоставляет все необходимые средства для решения проблемы масштабируемости.
Второе сомнение - что делать с теми объектами, которые уже хранятся в различных базах данных и используются в рамках существующих систем? Для того чтобы эти объекты могли быть использованы при создании новых интегрированных систем, их необходимо логически отразить в едином пространстве объектов без физического копирования. В этом случае действия над объектами в рамках единого пространства будут немедленно отражаться в действия над основными хранимыми объектами, обеспечивая логическую непротиворечивость информации. Такой подход позволит создавать новые системы как изначально интегрированные с существующими без осуществления отдельного интеграционного проекта.
Третье сомнение - есть ли принципиальная возможность обеспечить достаточный уровень информационной безопасности такого единого пространства объектов? Краткий ответ - да, так как публикация объектов может осуществляться на площадке владельца информации, соответственно можно применить как специальные средства защиты пространства объектов, так и стандартные (такие как VPN).
Остается главное сомнение - как это единое пространство объектов может помочь в решении интеграционных проблем? Если две системы изначально были разработаны по-отдельности, то ответ неутешителен - они не смогут взаимодействовать друг с другом без доработки. Доработка необходима, какая бы технология интеграции не использовалась, так как необходимо создать информационные связи между объектами разных систем.
Тогда возникает вопрос - зачем вообще нужно вводить некое пространство объектов, если существующие системы надо интегрировать по-прежнему с использованием репликации, ETL и других инструментов? Необходимо отметить, что данный подход, прежде всего, ориентирован на создание новых систем, интегрированных между собой по факту создания. Вновь создаваемые системы, оперирующие объектами через единое пространство, бесшовно интегрированы со всеми системами, работающими с теми же объектами, изначально. Это проявляется в том, что каждая система может читать, модифицировать и ссылаться на объекты независимо от формата и места их хранения, а, следовательно, конечные пользователи могут получать интересующую их информацию из различных систем без ограничений.
Но сказанное не означает, что данный подход не может эффективно применяться для интеграции существующих систем, которые не были изначально построены на едином пространстве объектов. Так, кроме собственно интеграции данных неких существующих систем, может потребоваться разработка новых пользовательских интерфейсов для работы с интегрированными данными, так как только в этом случае можно извлечь реальную пользу для конечных пользователей. Конечно, можно разработать модули к существующим приложениям, работающим напрямую с данными смежной системы, но эту работу в общем случае придется делать дважды для каждой пары интегрируемых систем - в рамках приложений обеих систем (зачастую даже в том случае, если пользовательский интерфейс к системе предоставляется с помощью WEB-браузера).
Выходом из этой ситуации может служить построение единого пространства объектов поверх интегрированных систем с последующей разработкой единого пользовательского интерфейса и алгоритмов обработки интегрированных данных через это пространство. Поступив так, мы достигаем не только единства пользовательского интерфейса, но и упрощаем процесс расширения кластера интегрированных систем. При интеграции других систем в этот кластер, достаточно будет опубликовать новые объекты в пространстве объектов, чтобы с ними можно было работать конечным пользователям, конечно, если новые объекты относятся к тем же типам, которые уже отображаются пользователю. Если же типы публикуемых объектов еще не охвачены пользовательским интерфейсом, то его придется дорабатывать, но сделать это надо будет один раз на каждый новый тип объектов.
Для создания отдельных изолированных систем нет никакой необходимости в едином пространстве объектов. Но как только мы говорим об интеграции ряда систем в одну метасистему, тут же возникает необходимость в выстраивании логически целостного пространства объектов тем или иным образом, с использованием той или иной технологии. Особенно, если системы, подлежащие интеграции, появляются не одномоментно. Без такого пространства решения будут лоскутными в большей или меньшей степени.
Может существовать масса различных подходов к организации единого пространства объектов, некоторые из которых уже реализованы в виде высококачественных продуктов (например, подходы к интеграции реляционных схем). Далее мы более детально изложим наше видение этого сложного вопроса, постараемся раскрыть мотивы каждого принятого архитектурного решения, не претендуя на абсолютную истинность и законченность изложения.
Ключевым свойством нашего предложения является его неограниченная масштабируемость, которая может быть полезна как в рамках отдельно взятой организации, так и глобально в рамках Сети в целом. Организационные вопросы, связанные с глобальным характером пространства объектов, требуют отдельного рассмотрения и здесь не раскрываются.
