
- •Введение
- •1. Основы, принципы, виды
- •1.1. Понятия и определения
- •1.1.1 Принципы распределенных бд
- •1.1.1.1 Локальная автономия и непрерывность
- •1.1.1.2 Прозрачность
- •1.1.1.3 Обработка
- •1.1.1.3 Прозрачность
- •1.2. Преимущества и недостатки
- •1.3 Виды распределенных баз данных
- •1.3.1 Виды распределенных баз данных (следующий слайд)
- •1.3.2 Виды распределенных баз данных (следующий слайд)
- •1.4. Сложности и возможные решения
- •1.5. Принципы открытого доступа и функциональной совместимости баз данных
- •1.6. Мультибазовые системы
- •1.6.1 Возможности мультибазовых систем
- •1.6.2 Возможности мультибазовых систем
- •1.7. Параллельные субд
- •1.7.1 Типы параллельных субд (следующий слайд)
- •1.7.1.1 Параллельная система без разделения вычислительных ресурсов
- •1.7.1.2 Параллельная система с разделением памяти
- •1.7.1.3 Параллельная система с разделением дисков
- •1.7.1.4 Преимущества и применение
- •2. Методы и средства реализации рбд
- •2.1. Фрагментация данных
- •2.1.1. Принцип горизонтальной фрагментации данных
- •2.1.2. Пример горизонтальной фрагментации данных
- •2.1.3. Принцип вертикальной фрагментации данных
- •2.1.4. Пример вертикальной фрагментации данных
- •2.1.5. Преимущества и недостатки
- •2.2. Репликация данных
- •2.2.1 Тиражирование
- •2.2.2 Модели тиражирования
- •2.2.3 Модели тиражирования
- •3. Уровни рбд
- •3.1 Глобальный уровень (не пропускать слайд)
- •3.2 Пользовательский уровень
- •3.3 Локализационный уровень
- •4. Архитектуры распределенных баз данных
- •4.1 Архитектуры распределенных баз данных
- •4.2. Архитектура «клиент-сервер»
- •4.2.3 Система «клиент-сервер»
- •4.2.4 Состав «клиент-сервер»
- •4.2.4.1 Состав «клиент-сервер»
- •4.2.4.2 Состав «клиент-сервер» (следующий слайд)
- •4.2.4.3 Состав «клиент-сервер» (следующий слайд)
- •4.2.4.4 Состав «клиент-сервер» (следующий слайд)
- •4.2.4.5 Состав «клиент-сервер» (следующий слайд)
- •5. Проектирование рбд
- •5.1 Проектирование рбд
- •5.2 Проектирование рбд (следующий слайд)
- •5.3. Базовые технологии.
- •5.3. Базовые технологии. Сравнение на понятийном уровне (следующий слайд)
- •5.3.1.1 Особенности
- •5.3.1.2 Преимущества и недостатки
- •5.3.2 Понятие о технологии corba
- •5.3.2.1. Технология corba
- •5.3.2.2. Особенности
- •5.3.2.2. Особенности (следующий слайд)
- •5.3.2.3 Преимущества и недостатки
- •Объектная архитектура распределенных систем.
- •5.3.3.1 Понятие о технологии ejb
- •5.3.3.2 Состав
- •5.3.3.3 Понятие о технологии .Net
- •5.3.3.4 Состав
- •6 Информационная безопасность
- •6.1 Источники угроз
- •6.1.1 Внутренние источники угроз
- •6.1.2 Технические средства
- •6.2 Объекты угроз информационной безопасности
- •6.2.1 Наиболее распространенные угрозы безопасности данных.
- •6.2.1.1 Внутренние угрозы безопасности данных.
- •6.2.1.2 Внешние угрозы безопасности данных.
5.3. Базовые технологии.
Функции CORBA и COM - это функции промежуточного middleware программного обеспечения объектной среды. Функциональность объекта предоставляется клиенту посредством обращения к абстрактным интерфейсам. Интерфейс определяет набор методов, присущие данному классу объектов. Клиент получает доступ к объекту только путем вызова метода, определенного в интерфейсе объекта, но детали реализации скрыты от клиента. Реальные действия выполняются в адресном пространстве объекта, возможно, удаленном по отношению к процессу клиента. Сокрытие деталей реализации и определяет независимость от платформы и языка программирования.
5.3. Базовые технологии. Сравнение на понятийном уровне (следующий слайд)
В обеих технологиях взаимодействие между клиентским процессом и сервером объекта, то есть процессом, который порождает и обслуживает экземпляры объекта, осуществляется за счет вызова удаленных процедур (RPC, remote procedure call). Механизм RPC реализует схему передачи сообщений, в соответствии с которой в распределенном клиент-серверном приложении процедура-клиент передает специальное сообщение с параметрами вызова по сети в удаленную серверную процедуру, а результаты ее выполнения возвращаются в другом сообщении клиентскому процессу.
Для этого на стороне клиента и на стороне сервера поддерживаются специальные компоненты, носящие название клиентский и серверный суррогаты (client stub и server stub). Для вызова метода объекта клиент обращается к клиентскому суррогату, который упаковывает аргументы в сообщение-запрос и передает их на транспортный уровень соединения. Серверный суррогат распаковывает полученное сообщение и в соответствии с переданными аргументами вызывает нужный метод объекта. В СОМ клиентский суррогат называется proxy, а серверный - stub. В CORBA клиентский суррогат не имеет специального названия, а серверный обозначают термином skeleton.
Параметры вызова могут формироваться в отличной от серверной языковой и операционной среде, поэтому на клиентский и серверный суррогаты возлагаются функции преобразования аргументов и результатов в универсальное, не зависящее от конкретной архитектуры представление. Тем самым достигается возможность взаимодействия клиента и сервера на различных платформах.
5.3.1 Понятие о технологии (D)COM(+)
Аббревиатура COM расшифровывается просто, это - Component Object Model - компонентная объектная модель. Иногда говорят и «модель COM». Сутью данной технологии является то, что программы строятся из компонент, которые состоят из объектов. Само по себе это обстоятельство не является последней новостью в области программостроения - модульная архитектура и объектно-ориентированный подход к построению программ давно являются признанными стандартами de facto.
5.3.1.1 Особенности
Технология COM есть технология, которая переносит все преимущества ООП, доступные программисту на уровне исходного текста, на двоичный уровень. Если в исходном тексте программист волен использовать «те» объекты и не использовать «эти», но теряет всяческий контроль над тем, что он делал, как только исходный текст был скомпилирован, то при использовании COM эти возможности сохраняются на протяжении всего жизненного цикла программы. Дополнительно к этому добавляются возможности разделения проекта на отдельные, повторно используемые, и двоичные компоненты. Т.е., если в результате «непосильного труда» у программиста получается что-то хорошее и нужное, хотя бы частично, кому-то другому, то, оформив это в виде COM-сервера, он смело может это распространять, не рискуя что-то потерять - ведь контроль за исходным текстом остается у него. В то же время все пользователи этого объекта будут его использовать так же, как и свой, «родной», объект.
COM-объект, это объект, который доступен так же, как и «локальный» объект данного проекта, хотя, фактически, он не располагается в данном проекте, а есть уже готовый двоичный исполняемый ресурс. COM может располагаться где угодно и DLL - не единственная форма его существования. COM-объект может жить и внутри EXE-модуля, который может исполняться независимо (параллельно!) от модуля, который использует этот объект, и даже - этот самый модуль может исполняться совсем на другом компьютере.