DCOM (курсовая работа)
Описание файла
PDF-файл из архива "DCOM (курсовая работа)", который расположен в категории "". Всё это находится в предмете "проектирование программного обеспечения автоматизированных систем" из 9 семестр (1 семестр магистратуры), которые можно найти в файловом архиве НИУ «МЭИ» . Не смотря на прямую связь этого архива с НИУ «МЭИ» , его также можно найти и в других разделах. Архив можно найти в разделе "курсовые/домашние работы", в предмете "проектирование по автоматизированных систем" в общих файлах.
Просмотр PDF-файла онлайн
Текст из PDF
Московский Энергетический Институт(Технический Университет)Кафедра Прикладной МатематикиКурсовой Проектпо курсу «Проектирование ПОАС»«DCOM»Студент:Группа:Ясенков Е.М.А-13-03Научный руководитель: Меньшикова К.Г.Москва 2007ВведениеDistributed Component Object Model (DCOM) - программная архитектура, разработаннаякомпанией Microsoft для распределения приложений между несколькими компьютерами в сети.Программный сервер на одной из машин может использовать DCOM для передачи сообщения (егоназывают удаленным вызовом процедуры) к серверу на другой машине. DCOM автоматическиустанавливает соединение, передает сообщение и возвращает ответ удаленного сервера. DCOMявляется развитием СОМ.Примеры распределенных приложений: многопользовательские игры, приложения дляобмена сообщениями, а также любое ПО с функцией «обновление программы».Приложения, которые разрабатывались как распределенные, могут совмещать различныхклиентов с различными мощностями посредством работы сервера со стороны клиента, если этовозможно, и - со стороны сервера, когда это необходимо.В дальнейшем будем опираться на следующую терминологию:• Компонент - составная часть распределенного приложения.• Распределенные вычисления - парадигма организации приложений, в которой различные частипрограммы могут исполняться на разных компьютерах в сети.• Remote Procedure Call (RPC) - удаленный вызов процедуры - сообщение, посылаемое по сети,которое позволяет программе, установленной на одном компьютере, инициировать выполнениенеобходимой операции на другом.Некоторые особенности DCOMНезависимость от языкаОбщим вопросом при проектировании и разработке распределенного приложения являетсявыбор языка или инструмента для данного сервера.
Язык обычно выбирают с учетом затрат наразработку, с учетом имеющейся квалификации и необходимого быстродействия. Как развитие СОМ,DCOM абсолютно не зависит от языка. Теоретически для создания СОМ-серверов можетиспользоваться любой язык и эти серверы могут использоваться большим числом языков иинструментов. Java, Microsoft Visual C++, Microsoft Visual Basic, Microsoft Visual C#, Borland Delphi,Borland C++ Builder - все они взаимодействуют с DCOM.Нейтральность DCOM по отношению к языку позволяет разработчику приложения выбиратьязык и инструменты, с которыми он чувствует себя наиболее свободно.
Независимость от языка, крометого, позволяет создавать приложения-серверы и приложения-клиенты на различных языкахпрограммирования.Управление соединениемDCOM управляет соединением клиентов к серверу используя счетчик ссылок. Когда клиентсоединяется с сервером, DCOM увеличивает значение счетчика ссылок. Когда клиент разрываетсоединение, DCOM уменьшает значение счетчика ссылок.
Если значение счетчика достигает нуля –клиент свободен.Для определения активности клиента DCOM использует протокол отслеживания, а именно:машина клиента посылает периодическое сообщение. При нарушении соединения DCOM уменьшаетсчетчик и освобождает сервер, если значение счетчика станет равным нулю. С точки зрения сервера,случай отключения клиента, случай аварии сети и случай поломки машины клиента регистрируютсяодним и тем же механизмом подсчета. Приложения могут использовать такой механизм подсчетасоединений для своего высвобождения.Во многих случаях поток информации между сервером и его клиентами не однонаправлен:серверу нужно инициировать некоторые действия со стороны клиента, например, извещение о том, чтодлительный процесс завершился, обновляются данные, просматриваемые пользователем (обзорновостей), или поступило следующее сообщение в чате или многопользовательской игре. Многиепротоколы усложняют процесс осуществления такого типа симметричной связи.
В DCOM каждый2сервер может быть одновременно провайдером и потребителем функциональности. Один и тот жемеханизм, одни и те же возможности управляют связью в обоих направлениях, облегчая организациюсвязи и взаимодействия клиент/сервер.DCOM предлагает устойчивый распределенный механизм регистрации соединений, который полностьюпрозрачен для приложения. DCOM - это одновременно симметричный сетевой протокол и модельпрограммирования, предлагающие не только традиционное взаимодействие клиент/сервер, но иполноценную связь между клиентами и серверами.Создание удаленного объектаСервисы создания объектов — одни из важнейших сервисов, предоставляемых СОМ.Клиенты обычно создают объекты, вызывая библиотеку СОМ или через моникеры (моникер — это имяопределённого экземпляра объекта, имя одного конкретного сочетания некоторого CLSID иперманентных данных).
Эти подходы работают и в DCOM, хотя и с некоторыми новымиособенностями. Рассмотрим различные варианты создания объектов, доступные клиентам.Использование CoCreatelnstanceНезависимо от того, где исполняется объект, клиент обычно создает его и затем получаетуказатели на необходимые интерфейс. Для большинства описанных ранее объектов — реализованныхсервером "в процессе" или локальным сервером — это можно сделать, вызвав CoCreateInstance, а затемс помощью QueryInterface запросить указатели на нужные интерфейсы. Клиент может создать объект наудаленной машине, вызвав ту же самую функцию, т.е.
клиенту даже не требуется знать, что объектвыполняется на другом компьютере. Чтобы создать удаленный объект, клиент вызываетCoCreateInstance, как обычно, передавая CLSID вместе с IID, указывающим первый интерфейс,указатель на который ему нужен.Однако для удаленного объекта необходимо задать дополнительный элемент — машину, накоторой он должен быть создан. Для объекта, создаваемого на той же машине, системный реестротображает CLSID в имя DLL или исполняемого файла, который должен быть загружен для данногокласса. А при создании объекта на удаленной машине системный реестр может отображать CLSID вимя машины, на которой этот объект должен создаваться.
Для создания удаленного объектаустанавливается связь с удаленной машиной, в ее реестре отыскивается данный CLSID, и на этойудаленной машине запускается соответствующий сервер. Если удаленный объект реализован в DLL, тозапускается суррогатный процесс, просто загружающий DLL (данная возможность не поддерживается впервой версии DCOM, но ее планируется реализовать как можно быстрее.).
Иначе запускается процессобъекта, как и в случае локального сервера.Рассмотрим несколько упрощенную картину создания удаленного объекта с помощьюCoCreateInstance. Клиент вызывает библиотеку СОМ для создания объекта с CLSID X, запрашиваяуказатель на интерфейс А этого объекта. Запись в реестре для CLSID X на клиентской машинесодержит имя другого компьютера. DCOM предоставляет несколько вариантов идентификацииудаленных машин в зависимости от сетевых протоколов, применяемых для доступа к удаленнойсистеме. DCOM поддерживает доменные имена, используемые TCP/IP, а также адреса IP (InternetProtocol), имена NetBIOS и имена, применяемые NetWare IPX/SPX.
Независимо от способаидентификации устанавливается связь с удаленной машиной, и там создается объект с учетоминформации о CLSID Х реестра удаленной машины. Удаленная машина запустит сервер, а затемпопросит его фабрику класса создать объект и вернуть указатель на интерфейс А. Этот указатель далеевозвращается клиенту как обычно. Для клиента все выглядит аналогично процессу создания новогообъекта локально.Как уже упоминалось, CoCreateInstance вызывает CoGetClass Object, чтобы получить фабрикуданного класса, а затем вызывает метод этой фабрики IClassFactory::CreateInstance для создания объектана локальной машине. Подобный процесс применяется и при создании объекта на удаленной машине,хотя бы с точки зрения программиста.
На самом же деле этот процесс был оптимизирован дляповышения производительности, и все эти действия выполняются за один цикл взаимодействия"запрос-ответ" с удаленной машиной.3Использование CoCreatelnstanceExПрименение CoCreateInstance для создания удаленного объекта не всегда наилучший вариант.Сколь велико ни было бы быстродействие сети, доступ к объекту на удаленной машине всегда будетмедленнее, чем доступ к объекту на локальной машине.
Даже для высокоскоростной сети лучшемаксимально сократить объем пересылаемых по ней данных. Таким образом, обеспечениепроизводительности, удовлетворяющей пользователей (и администраторов сетей), требуетминимизации количества запросов, необходимых для подготовки к использованию удаленного объекта.Важно при этом избежать излишних вызовов QueryInterface для удаленного объекта.С этой целью DCOM предоставляет функцию CoCreateInstanсеЕх, альтернативнуюCoCreateInstance. Как и CoCreateInstance, CoCreateInstanceEx позволяет клиенту задать CLSID классаобъекта, который он хочет запустить. Но если СоСrеаteInstance допускает указание только одного IID,задающего первый нужный интерфейс, то CoCreateInstanceEx дает клиенту возможность задать списокIID. После запуска объекта CoCreatelnstanceEx запрашивает у него указатели на все интерфейсы изэтого списка и возвращает их клиенту одновременно. Вместо того, чтобы заставлять клиентмногократно вызывать QueryInterface для получения указателей на интерфейсы объекта,одновременный возврат всех этих указателей может значительно ускорить процесс.