|
Еще один важный принцип, лежащий в основе архитектуры Е1 - поддержка компонентной модели. В соответветствии с данным принципом, модель реплицированных объектов расширяется до полноценной компонентной модели. Такая архитектура делает Е1 удобной платформой для разработки распределенных приложений.
Прежде чем перейти к обсуждению использования компонентных моделей в распределенных ОС, скажем несколько слов о компонентной парадигме программирования в целом.
В основе компонентно-ориентированного подхода к разработке программного обеспечения лежит идея создания программных систем на основе повторного использования готовых оттестированных компонентов. Компонент должен представлять собой самостоятельный продукт, который может использоваться третьей стороной, не участвующей в проектировании и имплементации данного компонента.
Компонент определяется как единица композиции с определяемыми договоренностью интерфейсами и явными контекстными зависимостями [54]. Компоненты являются объектами, т.е. обладают свойствами инкапсуляции, полиморфизма и доступности посредством интерфейсов. Однако, компоненты обладают дополнительными свойствами, не присущими объектам языка программирования. В отличие от объекта, компонент является программным продуктом. Это, в частности, означает, что разработка компонента и его использование могут осуществляться независимо различными сторонами. Компонент - это исполняемый модуль, а не сущность языка программирования. Поэтому для компонентов не поддерживается наследование имплементации. Повторное использование компонентов достигается путем композиции и агрегации. Для того чтобы два компонента были интероперабельными необходимо и достаточно, чтобы они были разработаны в соответствии с требованиями компонентной модели. При этом не имеет значения, разрабатывались ли они при помощи одного или разных языков программирования. Компоненты обладают большей самостоятельностью, чем объекты, и, как следствие, им свойственна большая гранулярность. Как правило, компонент строится из нескольких взаимосвязанных объектов языка программирования.
Компонентная модель определяет среду функционирования компонентов включающую: механизм защищенного взаимодействия, средства именования компонентов, механизм динамической загрузки классов, механизм сборки мусора, средства разработки компонентов, а также набор дополнительных сервисов, таких как механизм персистентности, транзакции, средства репликации компонентов, объектный трейдинг и т.д. (см., например, [36]).
Единая компонентная модель может поддерживаться в нескольких узлах сети. Такая среда удобна для разработки распределенных приложений, поскольку, помимо других преимуществ компонентно-ориентированной архитектуры, обеспечивает прозрачность сети, т.е., компоненты, расположенные в различных узлах, могут вызывать методы друг друга так же как в локальном случае. Данный подход реализован в системах промежуточного ПО, таких как COM [33], Corba [35], EJB [53].
Любопытно, что многие современные распределенные ОС предоставляют набор абстракций и сервисов, близких по содержанию к распределенным компонентным моделям промежуточного ПО. Вероятно, это объясняется тем, что их разработчики преследовали сходные цели: построить среду, обеспечивающую удобную и эффективную поддержку распределенных приложений. Для унификации доступа к ресурсам распределенные ОС, как правило, предоставляют объектно-ориентированный интерфейс. В некоторых реализациях объект является одним из основных примитивов ОС ([55], [21], [11]), в то время как другие системы предоставляют более простые примитивы, такие как порты сообщений в Mach[4] и Chorus[43] или порталы в Opal[10], на основе которых абстракция объекта реализуется объектно-ориентированной средой выполнения приложений. Для управления распределенными объектами ОС предоставляет сервисы, аналогичные ключевым сервисам компонентных моделей. В первую очередь, это механизм защищенного взаимодействия, позволяющий единообразно вызывать методы любого объекта при наличии соответствующих прав. Кроме того, все распределенные ОС поддерживают механизм глобального именования объектов, позволяющий получить доступ к объекту посредством некоторого уникального идентификатора. Некоторые распределенные ОС поддерживают также персистентность объектов [11, 10, 12, 49, 15].
Несмотря на указанные сходства, на сегодняшний день нельзя говорить о полноценной поддержке распределенными ОС компонентных моделей. Абстракция объекта в них рассматривается скорее как удобное средство межпроцессного взаимодействия, а не способ структурирования приложений. Как сервисы ОС, так и приложения строятся в виде набора серверных процессов, предоставляющих точки входа для взаимодействия с другими программами. Посредством точки входа сервер предоставляет операции для доступа к некоторому ресурсу или группе ресурсов. Для вызова этих операций используется объектная семантика. Клиент указывает идентификатор точки входа, требуемую операцию и набор параметров. После выполнения вызова сервер возвращает одно или несколько значений. Таким образом объект служит в основном коммуникационной абстракцией.
В то же время, компонентная парадигма программирования рассматривает объекты как самостоятельные программные сущности со своим собственным состоянием, контекстными зависимостями и четко определенной функциональностью. Такое представление плохо укладывается в архитектуру современных распределенных ОС. Это не означает, что в них исключается использование компонентной модели, но для ее реализации требуется промежуточный уровень программного обеспечения, подобный используемому в традиционных (не распределенных) ОС.
Авторы убеждены, что потенциально реализация полноценной распределенной компонентной модели на уровне ОС обладает существенными преимуществами по сравнению с использованием промежуточного ПО. Разработчик компонентно-ориентированного промежуточного слоя неизбежно приходит к реализации некоторой абстрактной машины поверх примитивов, предоставляемых ОС, что, естественно, приводит к снижению эффективности. В то же время, если ОС проектируется с учетом распределенной компонентной модели на всех уровнях, то существует возможность построить максимально эффективную и надежную имплементацию. Такой подход принят в архитектуре Е1, имплементирующей распределенную компонентную модель на основе реплицированных объектов. Все объекты, как прикладные, так и системные, существуют в рамках этой модели, т.е. являются компонентами.
Рассмотрим, чем компонентная модель Е1 отличается от объектных моделей существующих распределенных ОС. Наиболее существенным отличием являются примитивы выполнения Е1. В традиционных ОС основной абстракцией выполнения является процесс или задача, представляющая собой экземпляр программы, загруженной в память. Задача выполняется в изолированном адресном пространстве. С задачей может быть связано несколько потоков выполнения. Такая модель плохо адаптируется для поддержки взаимодействующих объектов средней гранулярности [18]. Поэтому мы отказываемся от нее в пользу новой модели выполнения, ориентированной на поддержку компонентных систем. В Е1 весь исполняемый код и данные принадлежат объектам. Все объекты расположены в едином 64-битном адресном пространстве. Для защиты объектов используется механизм страничной защиты памяти процессора. В Е1 используется модель мигрирующих потоков[18], в которой поток, выполняющий вызов метода объекта, переносит выполнение в вызываемый объект. Такая модель позволяет отойти от клиент-серверного подхода к разработке объектов, когда каждый объект должен запускать один или несколько потоков для обработки вызовов его методов.
Второй особенностью компонентной модели Е1 является то, что она основана на реплицированных объектах. Способность к репликации является неотъемлемым свойством каждого объекта. Е1 содержит развитые средства поддержки репликации, включающие мощный и очень гибкий механизм удаленного взаимодействия между репликами распределенного объекта, инструменты для управлением локальным состоянием объекта в каждом узле, расширяемую библиотеку стратегий репликации, а также специальный примитив синхронизации, необходимый для большинства стратегий репликации.
Помимо механизма репликации объектов, компонентная модель Е1 включает следующие элементы:
- Механизм защищенного взаимодействия, позволяющий выполнять вызовы методов любого объекта из любого узла системы. В Е1 все вызовы выполняются над локальной репликой вызываемого объекта. Правомерность каждого вызова проверяется распределенным сервером контроля доступа (СКД). Архитектура СКД обеспечивает большую степень свободы при выборе конкретной модели защиты.
- Репозиторий классов и механизм динамической загрузки классов.
- Механизм глобального именования, обеспечивающий отображение уникального идентификатора объекта в список контактных точек данного объекта.
- Механизм сборки мусора, обнаруживающий и удаляющий неиспользуемые реплики объектов на основании анализа графа ссылок.
- Механизм персистентности, обеспечивающий контроль времени существования объектов путем надежного хранения целостного состояния объекта в долговременном хранилище.
- Средства поддержки разработки компонентов, включающие компилятор языка описания интерфейсов Е1 и компилятор стратегий репликации.
В рамках единой компонентной модели Е1 разрабатываются как объекты ОС, так и всё прикладное ПО. Поэтому важнейшими требованиями к реализации модели являются минимизация связанных с ней накладных расходов, высокая гибкость и эффективность.
|