Реализация вызова удаленных процедур по технологии DCOM

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

Для того, чтобы устранить этот недостаток, специалисты Microsoft разработали распределенную модель СОМ - DCOM. Модель DCOM расширяет возможности СОМ, позволяя обращаться к СОМ объектам в режиме удаленного доступа.

Распределенная модель DCOM разработана для того, чтобы обеспечить взаимодействие между СОМ объектами в режиме удаленного доступа. Это позволяет СОМ серверу и СОМ клиентам располагаться на разных компьютерах и связываться по сети. По сути, механизм поддержки DCOM реализует те же задачи, что и механизм поддержки СОМ, но дополнительно он обеспечивает безопасность приложений в сетевой среде. Создание DCOM стало возможным в результате расширения возможностей механизма удаленного вызова процедур RPC и превращение его в объектный (Object) RPC. В настоящее время эту модель можно рассматривать как средство реализации распределенных многоплатформенных приложений.

В модели DCOM используется концепция "прозрачности размещения", которая подразумевает, что можно, не изменяя программного кода, выполнить приложение СОМ сервера на разных компьютерах сети. При этом ни приложение-сервер, ни приложение-клиент не "знают", на каком компьютере фактически работает "собеседник". Они могут выполняться на одном компьютере, на разных компьютерах локальной сети, или даже на разных компьютерах, подключенных к глобальной сети, например Internet. Приложение-клиент "узнает" о существовании сервера из данных в системном реестре, которые могут быть легко изменены.

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

Клиентские и серверные DCOM-приложения должны следовать правилам аутентификации и авторизации. Это означает, что приложение должно пройти через определенную процедуру регистрации при попытке получить доступ к компьютеру, на котором выполняется серверное приложение. Сервер должен аутентифицировать (идентифицировать) клиента - проверить, действительно ли он является тем, за кого себя выдает, и авторизировать доступ - выяснить, имеет ли пользователь необходимые привилегии доступа.

Приложения DCOM могут полагаться на те параметры безопасности, которые хранятся в системном реестре Registry, или изменить эти параметры программно. Эти два подхода к реализации подсистемы безопасности получили наименования декларативной и программируемой безопасности.

Главной проблемой при программировании DCOM-приложений является как раз подсистема обеспечения безопасности.

модель DCOM базируется на модели СОМ. Целью создания СОМ была поддержка разработки компонентов, которые могли бы динамически активизироваться и взаимодействовать друг с другом. Компонент в СОМ - это исполняемый код, содержащийся в динамически компонуемой библиотеке (DLL) или исполняемой программе.

Сама по себе модель СОМ существует в виде библиотек, компонуемых с процессом. Изначально она разрабатывалась для поддержки так называемых составных документов (compound documents). Как мы говорили в главе 3, составные документы - это документы, построенные из разнородных частей, таких как текст (форматированный), изображения, электронные таблицы и т.п. Каждая из этих частей может быть отредактирована при помощи ассоциированного с ней приложения.

Для поддержки бесчисленного множества составных документов Microsoft нужен был обобщенный метод для разделения отдельных частей и объединения их в единую сущность. Вначале это привело к технологии связывания и внедрения объектов (Object Linking and Embedding, OLE), Первая версия OLE использовала для передачи информации между частями документа примитивный и негибкий способ обмена сообщениями. Вскоре она была заменена следующей версией, также называвшейся OLE, но построенной на базе более гибкого механизма СОМ, что привело к появлению структуры, представленной на рис. 5.

Рис. 5 - Общая структура ActiveX, OLE и COM

На рисунке также показан элемент ActiveX - этим термином в настоящее время называют все, что относится к OLE, плюс некоторые новшества, к которым относят гибкую (как правило) способность компонентов выполняться в разных процессах, поддержку сценариев и более или менее стандартную группировку объектов в так называемые элементы управления ActiveX. Среди экспертов по DCOM (даже внутри Microsoft) не существует согласия по вопросу о точном определении ActiveX, поэтому мы даже не будем пытаться дать подобное определение.

Модель DCOM добавила к этой структуре весьма существенную вещь - способность процесса работать с компонентами, размещенными на другой машине. Однако базовый механизм обмена информацией между компонентами, принятый в DCOM, очень часто совпадает с соответствующими механизмами СОМ. Другими словами, для программиста разница между СОМ и DCOM часто скрыта за различными интерфейсами. Как мы увидим, DCOM в первую очередь предоставляет прозрачность доступа. Другие виды прозрачности менее очевидны.

Как и в CORBA, объектная модель в DCOM построена на реализации интерфейсов. Грубо говоря, объект DCOM - это просто реализация интерфейса. Один объект может реализовывать одновременно несколько интерфейсов. Однако в отличие от CORBA в DCOM имеются только бинарные интерфейсы (binary interfaces). Такой интерфейс, в сущности, представляет собой таблицу с указателями на реализации методов, которые являются частью интерфейса. Разумеется, для определения интерфейса по-прежнему удобно использовать специальный язык определения интерфейса (IDL). В DCOM также имеется такой язык под названием MIDL (Microsoft IDL - язык IDL от Microsoft), при помощи которого генерируются бинарные интерфейсы стандартного формата.

Достоинство бинарных интерфейсов состоит в том, что они не зависят от языка программирования. В случае CORBA каждый раз для поддержки нового языка программирования необходимо отображать описания IDL на конструкции этого языка. Подобная стандартизация в случае бинарных интерфейсов не нужна. Разницу между этими двумя подходами иллюстрирует рис. 6.

Рис. 6 - Разница между интерфейсами

Каждый интерфейс в DCOM имеет уникальный 128-битный идентификатор, который называется идентификатором интерфейса (Interface Identifier, IID), Каждый IID абсолютно уникален, не существует двух интерфейсов с одинаковым идентификатором IID. Этот идентификатор создается путем комбинирования большого случайного числа, локального времени и адреса сетевого интерфейса текущего хоста. Вероятность того, что два сгенерированных индикатора совпадут, практически равна нулю.

Объект DCOM создается как экземпляр класса. Чтобы создать такой объект, необходимо иметь доступ к соответствующему классу. Для этой цели DCOM содержит объекты класса (class objects). Формально таким объектом может быть все, что поддерживает интерфейс IClassFactory. Этот интерфейс содержит метод Createlnstance, который похож на оператор new в языках C++ и Java. Вызов метода Createlnstance для объекта класса приводит к созданию объекта DCOM, содержащего реализацию интерфейсов объекта класса.

Таким образом, объект класса представляет собой коллекцию объектов одного типа, то есть реализующих один и тот же набор интерфейсов. Объекты, принадлежащие к одному классу, обычно различаются только в части текущего состояния. Путем создания экземпляров объекта класса становится возможным обращение к методам этих интерфейсов. В DCOM на любой объект класса можно сослаться по его глобальному уникальному идентификатору класса (Class Identifier, CLSID).

Все объекты реализуют стандартный объектный интерфейс lUnknown. Когда путем вызова Createlnstance создается новый объект, объект класса возвращает указатель на этот интерфейс. Самый важный метод, содержащийся в lUnknown, - метод Querylnterface, который на основании IID возвращает указатель на другой интерфейс, реализованный в объекте.

Важное отличие от объектной модели CORBA состоит в том, что все объекты в DCOM нерезидентные. Другими словами, как только у объекта не остается ссылающихся на него клиентов, этот объект удаляется. Подсчет ссылок производится путем вызова методов AddRef и Release, входящих в интерфейс lUnknown. Наличие исключительно нерезидентных объектов делает невозможным хранение каждым из объектов своего глобально уникального идентификатора. По этой причине объекты в DCOM могут вызываться только по указателям на интерфейсы. Соответственно, как мы увидим позднее, для передачи ссылки на объект другому процессу необходимо предпринять специальные меры.

DCOM также требует динамического обращения к объектам. Объекты, запросы к которым могут создаваться динамически, во время выполнения, должны иметь реализацию интерфейса IDispatch. Этот интерфейс подобен интерфейсу динамического обращения (DII) в системе CORBA.

1.3 Разработка модели подсистемы СОС

2.2 Разработка и определение параметров приложения

Вычислитель матрицы - устройство управления объектом, позволяющее вводить в таблицу значения матрицы и производить над ними арифметические операции (вычислять детерминант).

Матрица представляет собой таблицу с пустыми ячейками, в которые пользователь может вводить значения.

Схематично можно изобразить вычислитель матрицы следующим способом:

Рис. 13 - Вычислитель матрицы

Класс матрицы Matrix:

Таблица 1 - Данные класса Matrix

Таблица 2 - Функции класса Matrix

Класс генератора случайных чисел RandGen:

Данные класса:

Функции класса:

Класс отрисовки матрицы View:

Данные класса:

Функции класса:

Анализ характерного поведения.

Матрица представляет собой совокупность столбцов, каждый из которых содержит заданное количество ячеек.

Матрица должна иметь:

Длину (количество столбцов).

Ширину(количество строк).

Как и все оконные элементы управления, вычислитель матрицы можно размещать на форме и изменять её размеры.

Необходимо предусмотреть возможность изменения количества строк и столбцов.

Объект, включающий в себя все эти части должен обладать следующими функциями:

Средство для рисования

Возможность ввести значение в любую ячейку

Добавлять строку

Добавлять столбец

Устанавливать ширину столбцов и строк

Изменять свои размеры

Возможность заполнить матрицу случайными значениями

Возможность вычислить минимальное и максимальное значение

Возможность вычислить детерминант.

На основе анализа предметной области были написаны следующие классы:

Класс матрицы.

class Matrix

{

public:

Matrix();

Matrix(Matrix &m);

~Matrix();

void SetSize(int m, int n);

void Fill(int val);

int FindMax();

int FindMin();

void SetElem(int i, int j, int val);

int GetM();

int GetN();

int GetElem(int i, int j);

void SetGen(RandGen * pG);

void FillRand();

int Determ();

Matrix& DelLine(int k);

Matrix& DelCol(int k);

private:

int M;

int N;

int ** A;

RandGen* pGen;

};

2. Класс генератора случайных чисел.

class RandGen

{

public:

RandGen();

~RandGen();

void Init();

int Get();

void SetInterval(int i_min, int i_max);

int GetMin();

int GetMax();

private:

int min;

int max;

};

Класс отрисовки матрицы.

class View

{

public:

View();

~View();

void Draw(TCanvas * Canvas);

void SetMatrix(Matrix * pM);

int GetSizeX();

int GetSizeY();

void SetSizeX(int size){SizeX = size;}

void SetSizeY(int size){SizeY = size;}

private:

int SizeX;

int SizeY;

Matrix * pMatr;

};

2.3 Формализация требований к программному средству

Программа должна состоять из двух модулей - сервера автоматизации и клиента.

Сервер и клиент должны поддерживать взаимодействие как в пределах одного компьютера, так и по сети.

Использование технологии DCOM при реализации.

Основные требования к серверу:

-Динамическое отображение изменений характеристик клиента.

-Поддержка взаимодействия с несколькими клиентами.

Основные требования к клиенту:

-Возможность установления/разрыва соединения с сервером.

-Наличие методов и средств изменения параметров сервера.

2.4 Выбор инструмента разработки и его обоснование

В качестве языка программирования был выбран объектно-ориентированный язык С++. Среда разработки - зарекомендовавший себя продукт Borland Builder C++ 6.

2.3 Реализация приложения

Сервер.

В сервере необходимо реализовать графическое отображение объекта и его характеристик.

Рис. 14 - Внешний вид приложения сервера

Для того, чтобы определенные данные сервера были доступны для внешнего мира, воспользуемся библиотекой типов. А именно - зададим определенные свойства (и опишем методы доступа к ним):

Свойства:

- Количество строк

- Количество столбцов

- Длина ячейки

- Ширина ячейки

- Минимальное значение элемента

- Максимальное значение элемента

Методы:

- установить размеры ячейки

- установить конкретное значение всем ячейкам

- получить максимальный элемент матрицы

- получить минимальный элемент матрицы

- получить количество строк

- получить количество столбцов

- получить элемент матрицы

- установить случайное сгенерированное значение

- вычислить детерминант.

При изменении свойств из клиентского приложения на сервере отображается изменение параметров реостата.

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

После этого пользователь определяет интерфейс посредством библиотеки типов.

Рис. 15 - Определение интерфейса сервера в библиотеке типов

Клиент:

В клиенте реализована возможность соединения/разъединения связи с сервером, изменение свойств сервера.

Изменение количества строк и столбцов, а также конкретных значений элементов реализована с помощью соответствующих текстовых полей.

Рис. 16 - Схема взаимодействия для локального и удаленного вариантов приложений

приложение локальный параметр

Описание взаимодействия клиента и сервера:

Для осуществления взаимодействия в клиенте имеются две кнопки:

-выполнить подключение

-прекратить подключение

При нажатии на первую кнопку вызывается функция CreateOleObject() с параметром Kurs.AmpAuto - имя созданного нами com-объекта (от клиента поступает запрос операционной системе для установления связи с сервером. Операционная система ищет в своем реестре объект, указанный в запросе (Kurs. AmpAuto)).

Если объект не был найден, то работа клиента завершается ошибкой:

Рис. 17 - Сообщение о недоступном сервере RPC

Если же запись об OLE объекте была найдена в реестре, вызывается функция CoCreateInstance(), и в качестве одного из параметров ОС передает ей найденный в реестре CLSID, соответствующий имени объекта. Система обращается к серверу автоматизации. Создается фабрика класса, через интерфейс которой по данному CLSID создается экземпляр com-объекта. Компилятор генерирует код заместителя(proxy) и код заглушки(stub) на языке IDL. При нажатии на вторую кнопку связь между клиентом и сервером прекращается, объект автоматизации уничтожается.

Для взаимодействия клиента и сервера в разных адресных пространствах используются proxy и stub. Когда клиент хочет вызвать некоторый метод интерфейса, он обращается к proxy, который упаковывает параметры метода в стандартный формат для пересылки между процессами и передает запрос и параметры в процесс com-объекта (Эта процедура называется Маршаллинг). В сервере с помощью stub происходит распаковка параметров из стандартного формата и вызов метода внутри объекта (Эта процедура называется Демаршаллинг). Процедуры межпроцессовых взаимодействий осуществляются посредством ОС.

Результат работы программы:

Рис. 18 - Внешний вид приложения сервера

Увеличим длину ячеек и количество строк:

Рис. 19 - Внешний вид приложения клиента

Результат:

Рис. 20 - Внешний вид сервера после внесенных изменений

Заключение

DCOM позволяет клиенту создавать и использовать объекты, как на удаленных системах, так и на локальной. Подобно тому, как клиенты СОМ имеют прозрачный доступ к объектам в динамических библиотеках и локальных процессах, DCOM обеспечивает прозрачный доступ к объектам в удаленных процессах.

Несмотря на отдельные сложные моменты, DCOM проста для понимания. Она добавляет к знакомым основам СОМ всего 3 основных элемента: способ создания удаленного объекта, протокол вызова методов этого объекта и механизмы обеспечения безопасного доступа к нему.

В данной курсовой работе был реализован вызов удаленных процедур(RPC) по технологии DCOM, используя объектно-ориентированный язык программирования Borland Builder C++. Клиентское приложение имеет возможность запустить серверное приложение на удаленном компьютере и вызвать необходимые ему методы или установить соответствующие свойства.

Литература

1. Э. Таненбаум, М. ван Стен Распределенные системы. Принципы и парадигмы - СПб: Питер, 2002г.

2. А. Олифер, В.Г. Олифер Сетевые операционные системы - СПб: Питер, 2002г.

3. Дейл Роджерсон. Основы COM. M.: Издательский отдел.Русская редакция., 1997

4. http://mediaplaneta.net/?page_id=253

Приложение

Исходные тексты программ

Сервер:

Main.h

#ifndef MainH

#define MainH

//------------------------------------------------------------------

#include <Classes.hpp>

#include <Controls.hpp>

#include <StdCtrls.hpp>

#include <Forms.hpp>

#include <ExtCtrls.hpp>

#include <ComCtrls.hpp>

//------------------------------------------------------------------

class TMainForm : public TForm

{

__published:// IDE-managed Components

TImage *image;

TLabel *Label3;

TLabel *Label4;

TLabel *Label7;

private:// User declarations

public:// User declarations

__fastcall TMainForm(TComponent* Owner);

void __fastcall Draw();

void __fastcall drawPos(int p,double s);

};

class TReostat

{

private:

double r;

int pos;

int nc;

double step;

public:

__fastcall TReostat(){r=0;pos=0;nc=9;step=20;};

int __fastcall GetPosition(){return pos;};

double __fastcall GetR(){return r;};

int __fastcall GetNC(){return nc;};

double __fastcall GetStep(){return step;};

void __fastcall SetPosition( int val ){pos = val;};

void __fastcall SetNC( int val ){nc = val;};

void __fastcall SetStep( double val ){step = val;};

void __fastcall SetR( double val ){r = val;};

};

extern PACKAGE TMainForm *MainForm;

#endif

Main.cpp

//--------------------------------------------------------------------

#include <vcl.h>

#pragma hdrstop

#include "Main.h"

#include <math.h>

//--------------------------------------------------------------------

#pragma package(smart_init)

#pragma resource "*.dfm"

TMainForm *MainForm;

//Coil - виток проволоки реостата

//NC - количество витков

//--------------------------------------------------------------------

__fastcall TMainForm::TMainForm(TComponent* Owner)

: TForm(Owner)

{ Label3->Caption="Сопротивление реостата (Ом):";

Draw();

TReostat *Reostat = new TReostat();

}

//--------------------------------------------------------------------

void __fastcall TMainForm::Draw()

{ TReostat *Reostat = new TReostat();

Reostat->SetNC(10);

Reostat->SetPosition(4);

//начальная позиция - 30

//конечная позиция - 530

//диапазон - 500

Reostat->SetStep( 500/(Reostat->GetNC()-1));

TCanvas *o = image->Canvas;

o->Brush->Color = clWhite;

o->FillRect( image->ClientRect );

o->Pen->Color = clBlack;

double X = 30, Y = 50, Y1 = 150;

for(int i=0;i<Reostat->GetNC();i++)

{

o->MoveTo(X,Y);

o->LineTo(X,Y1);

if(i!=(Reostat->GetNC()-1))

{

o->MoveTo(X,Y);

o->LineTo((X+Reostat->GetStep()),Y1);

}

else break;

X+=Reostat->GetStep();

}

X = 30;

Y = 100;

o->MoveTo(X-20,Y);

o->LineTo(X,Y);

o->MoveTo(X+560,Y);

o->LineTo(X+520,Y);

o->LineTo(X+520,Y-80);

drawPos(Reostat->GetPosition(),Reostat->GetStep());

}

//--------------------------------------------------------------------

void __fastcall TMainForm::drawPos( int p, double s )

{ TCanvas *o = image->Canvas;

o->Pen->Color = clBlack;

double X = 30;

X+=p*s;

double Y = 50;

o->MoveTo(X,Y);