- •1.Системный подход к построению информационно-управляющих систем (иус)
- •2. Информационные системы и технологии современного предприятия
- •3. Внедрение информационных технологий на основе бизнес-моделирования
- •4. Этапы развития корпоративных информационных систем
- •5. Офисный и технический документооборот в организации производства
- •6.Корпоративные информационные системы
- •7. Основы методологии mrp
- •8. Технология управления расширенной производственной цепочкой
- •Дисциплина
- •9. Тенденции создания и развития иус
- •10. Необходимость создания и внедрения асоиу
- •2. Создаем асу под бизнес, а не наоборот
- •11. Причины одновременного существования erp и scm-систем
- •12. Интеллектуализация асоиу
- •13. Задачи интеграции в гетерогенной информационной среде современного предприятия
- •14. Функциональные уровни приложений в корпоративных информационных системах
- •15. Архитектурные решения корпоративных информационных систем
- •16. Цель использования международных стандартов
- •17. Распределенные объектные архитектуры
- •18. Технологии создания распределённых объектных систем
- •Почему corba?
- •19. Архитектура управления объектами
- •20. Объектная модель corba
- •21. Спецификации служб omg
- •22. Характеристики стандартов idef
- •23. Основы методологии idef
- •24. Системы распределенного искусственного интеллекта
- •25. Перспективы развития информационных технологий ворганизационно-экономических системах
21. Спецификации служб omg
OMG (Object Management Group) - это международный консорциум, включающий более 500 компаний, связанных с производством компьютерной аппаратуры и программного обеспечения (в частности, членами OMG являются компании IBM, Digital Equipment, Hewlett Packard, Intel, Microsoft, Borland International, Oracle, Informix Software, Sybase и т.д.). Основной задачей OMG является разработка архитектуры и методов реализации программного обеспечения, которое в объектно-ориентированном стиле позволило бы выполнить интеграцию существующих и заново разрабатываемых (не обязательно объектно-ориентированных) информационно-вычислительных ресурсов. OMG регулярно выпускает спецификационные документы, которые становятся фактическими промышленными стандартами. Основными составляющими подхода OMG являются базовая объектная модель (Core Object Model), эталонная модель архитектуры (OMA - Object Management Architecture) и более приближенная к реализации общая архитектура брокера объектных заявок (CORBA - Common Object Request Broker Architecture).
В настоящее время OMG приняты, или наxодятся в процессе формирования спецификации следующиx служб:
Служба Уведомления Объектов о Событии (Event Notification Service).
Служба Жизненного Цикла Объектов (Object Lifecycle Service).
Служба Именования Объектов (Name Service).
Служба Долговременного Хранения Объектов (Persistent Object Service).
Служба Управления Конкурентым Доступом (Concurrency Control Service).
Служба Внешнего Представления Объектов (Externalization Service).
Служба Объектных Связей (Relationships Service).
Служба Транзакций (Transaction Service).
Служба Изменения Объектов (Change Management Service).
Служба Лицензирования (Licensing Service)/
Служба Объектных Свойств (Properties Service).
Служба Объектных Запросов (Object Query Service).
Служба Безопасности Объектов (Object Security Service).
Служба Объектного Времени (Time Service).
Служба уведомления объектов о событии (Event Notification Service). Служба обеспечивает извещение заинтересованных объектов о происходящих в системе событиях. Объект может выступать в качестве «производителя» или «потребителя» некоторого события. Для обеспечения асинхронного взаимодействия множества производителей событий с множеством их потребителей используются специальные объекты – «каналы событий», которые являются стандартными объектами CORBA. Сами события объектами не являются.
Служба жизненного цикла объектов (Object Lifecycle Service). Служба поддерживает создание, удаление, копирование и перемещение объектов. Для создания объектов используются специальные объекты «фабрики объектов» (object factories). Для определения положения таких объектов используется понятие локатора фабрики (factory finder). Для локаторов определена операция поиска, которая возвращает последовательность соответствующих фабрик. Клиенты задают локатор фабрик как параметр в операциях создания, копирования и перемещения. Такой подход к копированию и перемещению объектов обеспечивает независимость от ORB и механизма хранения. Операция удаления определяется для любого объекта, поддерживающего базовый интерфейс службы жизненного цикла. Поддерживается «поверхностное» и «глубокое» копирование.
Служба именования объектов (Name Service). Служба обеспечивает отображение между именами и объектами (связывание имен). Связывание имени всегда определяется относительно некоторого контекста именования. Контекст именования – это объект, который содержит множество связываний имен, и каждое имя в нем уникально. Несколько имен могут связываться с объектом в одном или различных контекстах одновременно. Необязательно, однако, чтобы все объекты были именованными. Поскольку контекст подобен другим объектам, он также может быть связан с именем в некотором контексте именования. При этом формируется направленный граф именования с узлами, представляющими контексты. Такой граф допускает более сложные имена для обращения к объекту. Служба поддерживает распределенные объединения пространств именования.
Служба долговременного хранения объектов (Persistent Object Service). Служба обеспечивает сохранение объекта независимо от времени жизни клиентов, осуществляющих доступ к объекту, и от реализации, обеспечивающей выполнение методов объекта. Состояние объекта представляется динамической частью (определяет представление в оперативной памяти и может не поддерживаться в течение всего периода жизни объекта) и статической частью, которая используется для реконструкции динамической части. Ключевой идеей объектных систем, критической для службы хранения, является возможность интеграции в данной архитектуре новых и уже существующих систем хранения.
Служба управления конкурентным доступом (Concurrency Control Service). Поддерживает конкурентный доступ к одному или более объектам со стороны одного или более объектов. Интерфейс службы позволяет выполнять вычисления в рамках транзакции (автоматическое освобождение блокировок по завершении транзакции – commit или abort) либо нетранзакционно (ответственность за своевременное разблокирование ложится на пользователя). Служба управления конкурентным доступом гарантирует правильную последовательность транзакционных и нетранзакционных вызовов по отношению друг к другу. Служба управления конкурентным доступом используется совместно со Службой управления транзакциями для координации выполнения конкурентных транзакций.
Служба внешнего представления объектов (Externalization Service). Спецификация службы определяет протоколы и соглашения по внешнему и внутреннему представлению объектов. Внешнее представление используется при записи объекта в поток передачи данных. Объекты, которые поддерживают соответствующие интерфейсы и чьи реализации удовлетворяют соответствующим соглашениям, могут быть направлены в поток (в память, в дисковый файл, через сеть и т. д.) и впоследствии преобразованы в новый объект в том же или в другом процессе. Допускается множество форм внешнего представления объекта, которые могут передаваться вне среды ORB и преобразовываться во внутреннее представление в среде другого ORB.
Служба объектных связей (Relationships Service). Служба обеспечивает средства для создания, удаления, навигации и управления связями между объектами. Служба определяет два новых вида объектов: связь и роль. Роль представляет CORBA-объект в некоторой связи. Объект-связь создается на основании множества ролей, передаваемого в фабрику связей. На связях можно задавать и проверять ограничения типа и кардинальности, при нарушении которых возникают исключительные ситуации. Для представления связей и ролей используется система типов IDL. Интерфейсы связей и ролей могут расширяться дополнительными атрибутами и операциями. Служба позволяет связывать так называемые немутабельные объекты.
Служба транзакций (Transaction Service). Служба предоставляет гарантию того, что вычисления поддерживают некоторые или все присущие транзакциям ACID свойства (атомарность, непротиворечивость, изолированность, постоянство). Транзакционная служба поддерживает два вида транзакций: плоские (flat) и гнездовые (nested). Клиент может посылать заявки к множеству объектов, размещенных в различных узлах сети, в рамках области действия транзакции. Поддержка таких распределенных транзакций требует от ORB возможности передачи «контекста транзакции» с каждой заявкой.
Служба изменения объектов (Change Management Service). Поддерживает идентификацию и согласованную эволюцию объектов. Сюда входит управление версиями существующих объектов, связанными наборами или конфигурациями объектов, и преобразованиями между соответствующими представлениями объектов.
Служба лицензирования (Licensing Service). Служба обеспечивает среду для спецификации и управления лицензионной политикой.
Служба объектных свойств (Properties Service). Позволяет связывать с объектом динамически создаваемые атрибуты. Посредством интерфейса, определенного службой, информация может быть связана с состоянием объекта (например, его заголовком или датой). Свойства являются динамическими эквивалентами атрибутов CORBA. Служба позволяет определять имена свойств, перечислять их, задавать им значения, получать значения по именам и удалять их.
Служба объектных запросов (Object Query Service). Осуществляет операции над наборами объектов. Операции имеют основанную на предикатах декларативную спецификацию и могут возвращать наборы объектов как результат. Служба запросов не должна нарушать инкапсуляцию объектов. Далее служба запросов рассматривается детальнее.
Служба безопасности объектов (Object Security Service). Контролирует доступ к объектам. Данная служба действует в пределах всей распределенной системы. Безопасность имеет дело с такими понятиями, как конфиденциальность и целостность информации, ответственность пользователей за свои действия, доступность информации. Дополнительные возможности в обеспечении безопасности могут предоставляться Общими средствами, использующими ядро системы безопасности, реализуемое службой безопасности.
Служба объектного времени (Time Service). Поддерживает механизм синхронизации в распределенной системе.
Помимо рассмотренных, имеется также ряд служб, которые впоследствии были связаны с другими компонентами OMA (Общими средствами и Брокером). Так, к Общим средствам отнесены организация архивов (archive service), резервное копирование (backup service) и восстановление (restore service), операционный контроль (operational control service). К функциям ORB отнесены поддержка репозитория реализаций (implementation repository), инсталляция и активизация объектов и реализаций (installation and activation service), поддержание репозитория интерфейсов (interface repository), обеспечение механизма дублирования информации (replication service), запуск объектных служб (startup services service).
Общие средства заполняют концептуальное пространство между ORB и объектными службами, с одной стороны, и прикладными объектами – с другой. Таким образом, ORB обеспечивает базовую инфраструктуру, Объектные службы – фундаментальные объектные интерфейсы, а задача Общих средств – поддержку интерфейсов сервисов высокого уровня, которые, впрочем, могут включать специализацию Объектных служб. Таким образом, операции, представляемые Объектными службами, предназначены, в частности, для использования Общими средствами и прикладными объектами. Реализуется это посредством наследования стандартных интерфейсов. Рассматриваемая ниже архитектура Общих средств также является предварительной и при уточнении должна согласовываться с общей архитектурой OMG. Общие средства подразделяются на две категории: «горизонтальные» и «вертикальные» наборы средств.
«Горизонтальный» набор средств определяет операции, используемые во многих системах и не зависящие от конкретных прикладных систем. «Вертикальный» набор средств представляет технологию поддержки конкретной прикладной системы (вертикального сегмента рынка, включающего здравоохранение, производство, управление финансовой деятельностью, САПР и т. д.). При этом возможна эволюция Общих средств, связанная с миграцией вертикальных средств, которые оказываются общими для ряда прикладных систем, в набор горизонтальных средств. Следует отметить, что грань между Объектными службами и Общими средствами, также как и между Общими средствами и прикладными объектами, не является жестко фиксированной. Она может изменяться вместе с развитием объектной технологии. Архитектурные требования определения Общих средств аналогичны требованиям, которые должны выполняться при определении Объектных служб.
