Типизация объектов

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

Существует единственный способ надежно решить проблему определения сущности для объекта - это ввести типизацию объектов. Каждый объект в таком случае должен относиться к некоторому типу, который должен однозначно определять соответствующую сущность реального мира. Например, объекты, которые относятся к типу "Человек" не являются звездами, но являются людьми, и наоборот. Типизация объектов определяет способ интерпретации всех объектов некоторого типа. Например, для людей имеет смысл задача исследования социальных связей, тогда как для звезд - расстояния между ними, но не наоборот.

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

Как же хранить типы объектов в пространстве объектов, чтобы доступ к ним был не менее эффективен, чем доступ к самим объектам? Выход прост - представить типы объектов как специальный вид объектов. В этом случае типы объектов, будучи также объектами, относятся к специальному типу, обозначающему сущность "Тип". Такое рекурсивное определение типов позволяет вести их обработку аналогично любому другому объекту.

Что если некоторая сущность является частным случаем другой сущности, например, сущность "Спортсмен" является частным случаем сущности "Человек", - к какому типу должен быть отнесен объект частной сущности в этом случае? Сложность состоит в том, что мы не можем один объект отнести к двум типам одновременно, но любой объект типа "Спортсмен" также должен относиться к типу "Человек", как быть? Для разрешения этого противоречия вводится понятие наследования типов.

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

Таким образом, для того, чтобы определить, принадлежит ли некоторый объект заданному типу, недостаточно просто проверить его собственный тип, но надо также просмотреть всех предков собственного типа. Если среди всего этого набора присутствует заданный тип, то объект считается принадлежащим этому типу, несмотря на то, что его собственный тип может отличаться. В нашем примере в соответствии с этим правилом каждый объект типа "Спортсмен" неизбежно является объектом типа "Человек".

Может ли в пространстве объектов существовать несколько типов для одной и той же сущности? Да, это возможно в том случае, если разработка типов ведется разными организациями без согласования друг с другом. В результате объекты, относящиеся к одной и той же сущности, но к разным типам, будут интерпретироваться по-разному. Пространство объектов, будучи физически единым, начинает логически разбиваться на части, не связанные между собой.

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

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

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

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

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

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

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