«Открытые системы»
В результате процессов слияния и расширения предприятий их информационные системы превращаются в сложный конгломерат, состоящий из аппаратного обеспечения, операционных систем, СУБД и приложений. Эксплуатация и дальнейшее развитие таких систем превращается в сложнейшую задачу. На аппаратном уровне в качестве средства для выхода из создавшегося положения предлагаются централизованные, допускающие масштабирование центры обработки данных следующего поколения. На уровне приложений признание получила концепция сервис-ориентированных архитектур (Service-Oriented Architecture, SOA). Если эту концепцию предельно упростить, то можно сказать, что SOA — это способ сборки динамических, сложных прикладных систем из отдельно стоящих, автономных программных модулей.
Итак, казалось бы, решение проблемы масштабирования найдено: центр обработки данных можно по мере необходимости достраивать из имеющихся на рынке массовых компонентов, а с технологиями SOA сборка приложений из модулей-сервисов тоже не составляет особенных проблем. Все так, но только до тех пор, пока отдельные приложения существуют независимо друг от друга, если каждое из них оперирует своим собственным, не пересекающимся с остальными приложениями набором данных. При условии независимости по данным, для создания единой системы действительно достаточно ограничиться традиционными представлениями о SOA и еще об одной ключевой концепции, так называемой «корпоративной сервисной шине» (Enterprise Service Bus, ESB).
Но реальное предприятие представляет собой единый производственный организм, его подразделения и средства автоматизации находятся во взаимной связи между собой. К примеру, производственные, административные, маркетинговые и другие подразделения находятся в процессе постоянного информационного обмена, поэтому приложения, автоматизирующие их работу, используют общие данные, по этой причине такие приложения не автономны и не независимы.
В реальной практике корпоративные данные распределены между приложениями, и отдельное приложение оперирует заданным подмножеством от общего собрания корпоративных данных, причем подмножества, принадлежащие различным приложениям, могут пересекаться. Как следствие, возникает проблема дублирования данных. Если данные эти имеют одинаковое представление, то решение проблемы дублирования сводится к периодической синхронизации, но исторически вполне могло сложиться и так, что формы представления одних и тех же данных в разных приложениях могут не совпадать, что создает дополнительные сложности. В результате фундаментом внедряемой формально архитектуры SOA остается морально устаревшее неупорядоченное нагромождение источников данных, что, по сути, приводит к отрицанию самой идеи внедрения SOA как средства упрощения информационной системы предприятия, придания ей возможности для масштабирования.
К тому же обычно прикладные сервисы должны обладать всеми полномочиями для работы с данными — создавать, читать, изменять и удалять данные. Как следствие, открывается возможность рассогласования приложений по данным. Такое рассогласование можно разделить на две категории: рассогласование по атрибутам, когда различные системы обращаются к одним и тем же объектам, но они используют различные атрибуты этих объектов; рассогласование по объектам (в процессе работы подсистем могут появляться новые объекты).
Решением проблемы рассогласования данных может стать создание единой для всего предприятия «сервисной архитектуры данных» (Data Service Architecture, DSA). Чаще всего под DSA понимают введение дополнительного уровня в модель SOA; данный уровень стали называть «уровнем сервиса данных» (Data Service Level, DSL). Этот уровень обеспечивает абстракцию и интеграцию данных с точки зрения бизнес-сервисов. DSL обеспечивает целостный взгляд на корпоративные данные и интерфейс к данным, независимый от конкретных форм их хранения и представления.
Реализовать уровень сервиса данных можно в виде так называемой «информационной сервисной шины» (Information Service Bus, ISB) по аналогии с корпоративной сервисной шиной предприятия. Концепция ISB пока находится в процессе становления, и еще ни один производитель не готов предложить законченное коммерческое решение.
Частично принципы DSA реализованы в универсальной сервисной архитектуре данных Universal Data Services Architecture, предложенной компанией Informatica, в продукте BEA AquaLogic Data Services Platform (прежде известном как Liquid Data), поставляющем данные посредством сервисов, а также в DataXtend от компании Progress Software.
Информационная сервисная шина
Внедрение сервисной архитектуры данных позволяет развить далее принцип «слабой связанности», составляющий основу SOA и обеспечивающий этой архитектуре важнейшие преимущества по сравнению с монолитными архитектурами. Наличие DSL позволяет архитекторам баз данных осуществлять необходимые действия, не ограничивая себя требованием сохранять интерфейсы в неизменности
