Учебнопрактическое пособие Владимир 2021
 Скачать 7.94 Mb.
|
|
4.2. Средства для проектирования и разработки серверного программного обеспечения Виды серверных программ Серверные программы делятся на следующие четыре вида. 235 Исполняемые программы, работающие через интерфейс CGI (Common Gateway Interface — общий интерфейс обмена), так называемые CGI-npoграммы. Эта разновидность серверных программ — самая старая, однако отнюдь не устаревшая. Расширения Web-сервера (приложения формата ISAPI, NSAPI, модули расширения Apache и т. п.). Новый способ, позволя- ющий встраивать серверные программы в сам Web-сервер, делая их его составными частями. Впервые предложен фирмой Microsoft для их сервера Microsoft Internet Information Server (интерфейс ISAPI) и разработчиками популярного бесплатного Web-сервера Apache. Активные серверные страницы (ASP, JSP и др.). Фактиче- ски это обычные статические Webстраницы, сохраненные в файлах, Которые, кроме обычного HTML-кода, включают в себя команды, обрабатываемые либо самим Web-сервером, либо его расширением. Также новый способ, впервые предложенный Microsoft для того же Internet Information Server. Серверные сценарии, написанные на интерпретируемом языке (Perl, Python, VBScript, JavaScript и др.). Обычные сценарии, работающие через интерфейс CGI или ISAPI на стороне сервера. Описание серверных программ, работающих через интерфейс CGI. CGI-программы представляют собой обычные исполняемые файлы, написанные на любом языке программирования и откомпили- рованные в машинный код процессора. Они не имеют интерфейса пользователя (как и все серверные программы), а работают с Web- сервером, получают от него входные данные и ему же пересылают результаты своей работы. Запускаются они самим Web-сервером, ко- гда в них возникает нужда (когда необходимо обработать полученные от пользователя данные), и работают под управлением операционной системы серверного компьютера. При этом, если Web-серверу посту- пает одновременно несколько запросов на обработку данных от поль- 236 зователей, он запускает соответствующее количество копий CGI- программы. К достоинствам CGI-программ можно отнести легкость созда- ния (многие среды разработки программ поддерживают создание та- ких приложений, в частности популярнейший Borland Delphi, начиная с версии 3) и простоту отладки. Также, поскольку CGI-приложения представляют собой независимые программы, они выполняются от- дельно от Web-сервера (как говорят программисты и системные ад- министраторы, выполняются в другом адресном пространстве). Это значит, что при сбое в CGI-программе завершается только она — сам Web-сервер остается "на плаву". А недостаток у CGI-программ всего один: большой расход системных ресурсов, поскольку для обработки каждого набора данных запускается отдельная копия серверной про- граммы. И если Web-серверу поступит слишком много запросов на обработку данных, серверный компьютер может и зависнуть. Web-сервера. Расширения Web-сервера — более новая разновидность сервер- ных программ. Они представляют собой обычные библиотеки DLL, в которых реализована вся логика серверной программы. Такие биб- лиотеки как бы встраиваются в программу Web-сервера и работают как ее неотъемлемая часть. Поскольку библиотеки DLL работают только в среде Windows, для того чтобы создавать расширения в иных операционных системах, были придуманы и другие форматы. В част- ности, модули расширения сервера Apache не являются библиотеками DLL, Именно в виде библиотек DLL создаются расширения Web- серверов Internet Information Server фирмы Microsoft и Netscape Web Server фирмы Netscape. В первом случае расширения имеют формат ISAPI (Internet Server Application Programming Interface — интерфейс программирования приложений интернет-сервера), а во втором — NSAPI (Netscape Server Application Programming Interface — интер- 237 фейс программирования приложений сервер: Netscape). Формат мо- дулей расширения Apache так и называется — модули Apache. Достоинство у расширений Web-сервера одно: бережный расход системных ресурсов. Дело в том, что для обработки всех наборов данных пользователя запускается всего один экземпляр расширения, который отнимает существенно меньше ресурсов, чем уйма запущен- ных CGI-программ. Однако расширения труднее создавать и отлажи- вать, к тому же они не так безопасны. Как CGI-программы. Посколь- ку они работают как часть Web-сервера, любая ошибка в расширении приведет к зависанию сервера. Оба описанных выше вида серверных программ обладают од- ним огромным недостатком. Прежде чем они смогут работать, они должны быть написаны на языке программирования и откомпилиро- ваны в машинные коды процессора, что отнимает много времени, особенно при отладке. Конечно, откомпилированные программы ра- ботают быстрее интерпретируемых, т. е. тех, где каждая инструкция читается, расшифровывается и обрабатывается специальной про- граммойинтерпретатором. Но у интерпретируемых программ есть и свои преимущества, главными из которых являются простота и быст- рота написания. Две следующие разновидности серверных программ, которые будут описаны, как раз будут интерпретируемыми. Активные серверные страницы (ASP, JSP). Как уже говорилось, активные серверные страницы — это обычные Web-страницы, включающие в себя особые серверные сце- нарии, выполняемые самим Web-сервером или специальной сервер- ной программой (CGI-приложением или расширением Web-сервера). В частности, ASP (Active Server Pages — активные серверные страни- цы), поддерживаемые Microsoft Internet Information Server, и JSP (Java Server Pages — серверные стра- ницы, написанные на JavaScript), поддерживаемые рядом других Web-серверов, работают именно таким образом. Серверные страницы 238 ASP пишутся на языках JavaScript и VBScript, a JSP — только на JavaScript. Достоинства активных серверных страниц вы уже знаете: лег- кость и быстрота написания и простота отладки. Кроме того, по- скольку активные серверные страницы -- это обычные Web-страницы с "вкраплениями" программного кода, их написание легко освоят все, кто знаком с HTML. Недостаток: относительная медлительность и повышенные требования к системным ресурсам. Серверные сценарии. Серверные сценарии подобны активным серверным страницам тем, что являются интерпретируемыми, однако представляют собой "чистый" программный код, без HTML ''примесей". Интерпретатор практически всегда представляет собой CGI-программу, однако ничто не мешает разработать его в виде расширения Web-сервера. Сценарии обычно пишутся на языке программирования Perl, специально пред- назначенном для обработки текста; также используются языки Python, JavaScript, VBScript и даже (как говорят) язык командных файлов MS- DOS. Фактически писать сценарии можно на любом языке програм- мирования, для которого есть интерпретатор. Достоинства и недостатки серверных сценариев те же, что у ак- тивных серверных страниц. Однако сценарии потребляют исключи- тельно много системных ресурсов, даже больше, чем CGI- приложения. Ведь для обработки каждого набора данных пользовате- ля запускается своя копия интерпретатора, а интерпретатор, в свою очередь, расходует много ресурсов на обработку сценария. И все же, несмотря на это, сценарии — самый популярный способ создания серверных программ. Способы передачи данных по сети. На самом обобщенном уровне сеть - это система, которая позво- ляет производить обмен информацией. 239 Компьютерные сети можно классифицировать по ряду призна- ков, например: I) по территориальной распространенности: Локальные (ЛВС) - охватывающие ограниченную территорию (обычно в пределах удаленности станций не более чем на несколько десятков или сотен метров друг от друга). Корпоративные (масштаба предприятия) - совокупность связан- ных между собой ЛВС, охватывающих территорию, на которой раз- мещено одно предприятие или учреждение в одном или нескольких близко расположенных зданиях. Территориальные - охватывающие значительное географиче- ское пространство; среди территориальных сетей можно выделить се- ти региональные и глобальные, имеющие соответственно региональ- ные или глобальные масштабы. II) По топологии (Общая схема соединения компьютеров в локальной сети называется топологией сети). Топологии сети могут быть различными, среди них выделяют три базовые: Шинная (bus) - все сетевые компьютеры подключаются через определенные промежутки к магистральной линии и данные, переда- ваемые любой станцией, одновременно становятся доступными для всех других станций; Кольцевая (ring) - узлы связаны кольцевой линией передачи данных один за другим, при этом данные передаются по проводу в одном направлении; Звездная (star) - имеется центральный узел, от которого расхо- дятся линии передачи данных к каждому из остальных узлов. Ника- кие конфликты в сети с топологией звезда в принципе не возможны, потому что управление полностью централизовано. III) по способу управления. В зависимости от способа управ- ления различают сети: "клиент/сервер" - в них выделяется один или несколько узлов (их название - серверы, которые работают под управлением сервер- ной ОС), выполняющих в сети управляющие или специальные об- 240 служивающие функции, а остальные узлы (клиенты) являются терми- нальными, в них работают пользователи; одноранговые - в них все узлы равноправны, то есть пользова- тели самостоятельно решают, какие ресурсы своего компьютера (дис- ки, каталоги, файлы) сделать общедоступными по сети. Основным недостатком таких сетей является слабая защищенность информации от несанкционированного доступа; Обмен информацией производится по каналам передачи инфор- мации. Компьютеры могут обмениваться информацией с использова- нием каналов связи различной физической природы: кабельных, оптоволоконных, радиоканалов, инфракрасного диапазона э/м излу- чения. Общая схема передачи информации включает в себя отправите- ля информации, канал передачи информации и получателя информа- ции. Если производится двусторонний обмен информацией, то отпра- витель и получатель информации могут меняться ролями. Основной характеристикой каналов передачи информации является их пропуск- ная способность (скорость передачи информации). Пропускная спо- собность канала равна количеству информации, которое может пере- даваться по нему в единицу времени. 4.3. Принцип построения и работы распределенного приложения Шаблоны проектирования распределенных приложений. При распределении ответственности и разработке способов вза- имодействия объектов разработчику предоставляется достаточная свобода действий. Неудачный выбор метода распределения может привести к тому, что системы и их отдельные компоненты окажутся непригодными для поддержки, понимания, повторного использования и резервирования. Неудачи можно избежать, если при распределении ответственности применять принципы объектно-ориентированного проектирования. Некоторые из этих принципов систематизированы в шаблонах GRASP и применяются при разработке диаграмм взаимо- 241 действия, то есть при распределении ответственности между объек- тами и разработке способов их взаимодействия. В объектно-ориентированном проектировании шаблоном назы- вают описание проблемы по распределению ответственности и ее ре- шения. Результат решения проблемы это операции назначенные объ- екту для выполнения успешного (а в общем случае требуемого) сце- нария взаимодействия. В идеале шаблон должен содержать советы по поводу его применения в различных ситуациях. С этой точки зрения шаблоны являются основным механизмом для накопления и повтор- ного использования полезных принципов разработки программного обеспечения. Шаблон MVC (Model-View-Controller) Шаблон проектирования Model-View-Controller (далее просто MVC) использован в основе архитектурного решения первой среды программирования с графическим интерфейсом пользователя – Smalltalk-80. Согласно шаблону при проектировании следует разде- лять данные приложения, пользовательский интерфейс и управляю- щую логику на три отдельных компонента: модель, представление и контроллер – таким образом, что модификация одного из компонен- тов оказывает минимальное воздействие на остальные. Модель (Model) предоставляет данные предметной области представлению и реагирует на команды контроллера, изменяя свое состояние. Пред- ставление (View) отвечает за отображение данных предметной обла- сти пользователю, реагируя на изменения модели. Контроллер (Controller) интерпретирует действия пользователя, оповещая модель о необходимости изменений. Шаблон Expert Шаблон Expert, как указывалось выше, может быть представлен описанием проблемы распределения ответственности и описанием ее решения. 242 Проблема: каков наиболее общий принцип распределения от- ветственности между объектами при объектно-ориентированном про- ектировании? Решение: назначить ответственность информационному экспер- ту – классу, у которого имеется информация, требуемая для выполне- ния ответственности. При распределении ответственности шаблон Expert используется гораздо чаще любого другого шаблона. В нем определены основные принципы, которые давно используются в объ- ектно-ориентированном проектировании. Шаблон не содержит неяс- ных или запутанных идей и отражает обычный интуитивно понятный подход. Он заключается в том, что объекты выполняют действия, свя- занные с имеющейся у них информацией. Программирование клиентского уровня: HTML, Java, Jscript, CSS. Как следует из названия, клиентские языки обрабатываются на стороне клиента пользователя, а если проще - программы на клиент- ском языке обрабатывает браузер. Отсюда следует и недостаток – это то, что обработка скрипта зависит от браузера пользователя, и поль- зователь имеет полномочия настроить свой браузер так, чтобы он во- обще игнорировал написанные вами скрипты. При этом, если браузер старый, он может не поддерживать тот или иной язык или версию языка, на которую вы опираетесь. С современными браузерами таких проблем возникать не должно, к тому же языки программирования не так уж часто кардинально обновляются (раз в несколько лет) и луч- шие из них давно известны. Также код клиентского скрипта может посмотреть каждый, выбрав в меню “Вид” своего браузера вкладку “Исходный код” (или что-то в этом роде). Преимущество же клиентского языка заключается в том, что обработка скриптов на таком языке может выполняться без отправки документа на сервер. Это легче объяснить на примере: допустим, вам надо проверить правильно ли пользователь ввел e-mail (т.е., напри- мер, проверить в нем наличие “@”); чтобы это сделать пользователю, 243 надо было бы отправить форму с заполненными данными, потом до- ждаться, пока она обработается, и лишь после этого получить сооб- щение об ошибке (если она, разумеется, присутствует). Процесс слишком долгий. С клиентским же языком программа сразу проверит правильное заполнение формы перед отправкой, и, если необходимо, выведет ошибку. Отсюда же вытекает и то ограничение, что с помо- щью клиентского языка программирования ничто не может быть за- писано на сервер, то есть, например, с его помощью нельзя сделать гостевую книгу, потому что тогда надо записывать сообщения в ка- кой-либо файл на сервере. Самым распространенным из клиентских языков является JavaScript, разработчиками которого является компания Netscape (www.netscape.com) совместно с компанией SunMicrosystems (www.sun.com). Другой вариант клиентского языка это, например, VisualBasicScript (VBS). Программирование серверного уровня: C++, PHP, Python, Perl, Ruby, JSP, ASP.Net. Серверные языки программирования соответственно работают на стороне сервера. Во взаимодействии с базами данных они поддер- живают связь между пользователем и сервером. Получая запрос с ад- ресом веб-документа от браузера, серверные программы связываются с базой данных. БД отдаёт информацию о веб-странице скриптам сер- вера, и те обработав её, отсылают для интерпретации браузеру клиен- та, который и выводит результат совместной работы на монитор. До- стоинством серверных языков является их воистину безграничные возможности и то, что их работа не подвержена воздействию пользо- вателей и скрыта от их взоров. Недостаток — зависимость от про- граммного обеспечения хостера. Так же к недостаткам можно отнести и сложность освоения новичками серверных языков программирова- ния. Наиболее распространённые серверные языки программирова- ния: C++, Perl, Java, Php, Python. 244 Глава 5. ТЕХНОЛОГИЯ ПОСТРОЕНИЯ РАСПРЕДЕЛЕННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ 5.1. Технология COM/DCOM Технология COM в настоящее время широко применяется при разработке программного обеспечения, интеграции программных продуктов в единые информационные системы. Целью разработки COM-технологии являлось стремление к интеграции программного обеспечения через стандартизацию механизмов взаимодействия про- граммных модулей между собой. На основе данной технологии, кото- рая является масштабируемой, разработано огромное число техноло- гий, которые стали стандартами в разнообразных сферах применения информационных технологий – от управления технологическими процессами в промышленности до домашних персональных компью- теров. Массовое применение COM отчасти связано с мощью ее разра- ботчика, фирмы Microsoft. С этим приходится считаться, и каждый программный продукт, выпущенный под платформу Windows, для достижения коммерческого успеха обязан соответствовать инноваци- ям Microsoft. Технология COM (Component Object Technology) – объектно- ориентированная программная спецификация, предложенная Microsoft. COM предназначена для повышения надежности взаимо- действия программных продуктов между собой. Данная технология не определяет структуру программного продукта, язык программиро- вания и прочие детали реализации. COM является стандартом, кото- рый регламентирует модель программного объекта, соответствующий требованиям COM-технологии. Программный объект, созданный со- гласно спецификации COM называется COM-объектом. Данная тех- нология определяет механизм взаимодействия COM-объектов между собой. COM относится к так называемым двоичным стандартам, т.к. прилагается к оттранслированному в двоичный код программному объекту. Взаимодействие COM-объектов обеспечивается набором предопределенных подпрограмм, называемыми интерфейсами, до- 245 ступ к которым обеспечивается через уникальные идентификаторы интерфейсов GUID (Global Unique Interface Identifyer), уникальность которых гарантирует операционная система. Такой механизм схож с использованием указателей при доступе к объектам в объектно- ориентированных языках программирования, что дает возможность прозрачного управления объектами, т.к. доступ к ним обеспечивается через указатели. COM-технология расширяет этот механизм, перено- ся применение указателей (в виде GUID) для доступа к объектам на уровень операционной системы. Таким образом, COM-объекты могут быть прозрачно друг для друга модифицироваться, т.к. доступ к объ- ектам обеспечивается через GUID. COM технология включает в себя также библиотеку, в которой содержится набор стандартных интер- фейсов, которые определяют ядро функциональности COM и не- большой набор API функций, разработанных для создания COM- объектов и управления ими. Архитектура COM является расширяемой, и на ней базируются другие технологии Microsoft, такие как OLE и ActiveX. Эти техноло- гии в настоящее время являются расширениями операционной систе- мы, и определяют свои собственные правила работы и предлагают свои библиотеки для создания объектов и для управления объектами на основе данных технологий. Используя COM как основу, разработ- чики программного обеспечения получают возможность создавать свои собственные расширения таким образом, что программные объ- екты созданные, по правилам COM-технологии могут работать с дру- гими COM-объектами через унифицированный механизм взаимодей- ствия, который предлагает COM. COM использует такое понятие как «класс», которое по смыслу означает то же самое, что и в объектно-ориентированных средствах разработки. COM-объект является объектом COM-класса (COM class). COM-классы, для различия с классами в объектно- ориентированных языках, с помощью которых может создаваться приложение, обычно называются соклассами (CoClass). 246 Терминология СОМ Всякая новая технология приносит с собой новые термины для ее описания. СОМ-объект представляет собой двоичный код, который вы- полняет какую-либо функцию и имеет один или более интерфейс. СОМ-объект содержит методы, которые позволяют приложению пользоваться СОМ-объектом. Эти методы доступны благодаря СОМ- интерфейсам. Клиенту достаточно знать несколько базовых интер- фейсов СОМ-объекта, чтобы получить полную информацию о составе свойств и методов объекта. СОМ-объект может содержать один или несколько интерфейсов. СОМ-интерфейс применяется для объединения методов СОМ- объекта. Интерфейс позволяет клиенту правильно обратиться к СОМ- объекту, а объекту - правильно ответить клиенту. Названия СОМ- интерфейсов начинаются с буквы I. Клиент может не знать, какие ин- терфейсы имеются у СОМ-объекта. Для того чтобы получить их спи- сок, клиент использует базовый интерфейс lunknown, который есть у каждого СОМ-объекта. Пользователем СОМ-объекта называется приложение или часть приложения, которое использует СОМ-объект и его интерфейсы в своих собственных целях. Как правило, СОМ-объект находится в другом приложении. СОМ со-классы (coclass) - это классы, которые содержат один или более СОМ-интерфейс. Вы можете не обращаться к СОМ- интерфейсу непосредственно, а получать доступ к СОМ-интерфейсу через со-класс. Со-классы идентифицируются при помощи идентифи- каторов класса (CLSID). СОМ-объекты часто используют библиотеки типов. Библиотека типов - это специальный файл, который содержит информацию о СОМ-объекте. Данная информация содержит список свойств, мето- дов, интерфейсов, структур и других элементов, которые содержатся в СОМ-объекте. Библиотека типов содержит также информацию о 247 типах данных каждого свойства и Типах данных, возвращаемых ме- тодами СОМ-объекта. Технология DCOM (Distributed COM) - это распределенная СОМ-технология. Она применяется для предоставления средств до- ступа к СОМ-объектам, расположенным на других компьютерах в се- ти (в том числе и сети Internet). Каждый СОМ-объект имеет счетчик ссылок. Данный счетчик содержит число процессов, которые в текущий момент времени ис- пользуют СОМ-объект. Под процессом здесь подразумевается любое приложение или DLL, которые используют СОМ-объект, т. е. пользо- ватели СОМ-объекта. Счетчик ссылок на СОМ-объект нужен для то- го, чтобы высвобождать процессорное время и оперативную память, занимаемую СОМ-объектом, в том случае, когда он не используется. После создания и обращения к СОМ-объекту счетчик ссылок увели- чивается на единицу. Всякий раз, когда новое приложение подключа- ется к СОМ-объекту - счетчик увеличивается. Когда процесс отклю- чается от СОМ-объекта - счетчик уменьшается. При достижении счетчиком нуля память, занимаемая СОМ-объектом, высвобождается. При создании СОМ-приложения необходимо обеспечить сле- дующее: СОМ-интерфейс; СОМ-сервер; СОМ-клиент. Рассмотрим эти три составляющие СОМ-приложения более по- дробно. Клиенты СОМ связываются с объектами при помощи СОМ- интерфейсов. Интерфейсы -- это группы логически или семантически связанных процедур, которые обеспечивают связь между поставщи- ком услуги (сервером) и его клиентом. По правилам обозначения СОМ-объектов, интерфейсы СОМ- объекта обозначаются кружками справа или слева от СОМ-объекта. Базовый интерфейс lUnknown рисуется кружком сверху от СОМ- объекта. 248 Для примера, каждый СОМ-объект всегда поддерживает основ- ной СОМ-интерфейс lUnknown, который применяется для передачи клиенту сведений о поддерживаемых интерфейсах. Как уже говорилось выше, СОМ-объект может иметь несколько интерфейсов, каждый из которых обеспечивает какую-либо свою функцию. Ключевыми аспектами СОМ-интерфейсов являются следую- щие: Однажды определенные, интерфейсы не могут быть изме- нены. Таким образом, вы можете возложить на один интерфейс опре- деленный набор функций. Дополнительную функциональность мож- но реализовать с помощью дополнительных интерфейсов. По взаимному соглашению, все имена интерфейсов начи- наются с буквы I, например IPersist, IMalloc. Каждый интерфейс гарантированно имеет свой уникаль- ный идентификатор, который называется глобальный уникальный идентификатор (Globally Unique Identifier, GUID). Уникальные иден- тификаторы интерфейсов называют идентификаторами интерфейсов (Interface Identifiers, IIDs). Данные идентификаторы обеспечивают устранение конфликтов имен различных версий приложения или раз- ных приложений. Интерфейсы не зависят от языка программирования. Вы можете воспользоваться любым языком программирования для реа- лизации СОМ-интерфейса. Язык программирования должен поддер- живать структуру указателей, а также иметь возможность вызова функции при помощи указателя явно или неявно. Интерфейсы не являются самостоятельными объектами, они лишь обеспечивают доступ к объектам. Таким образом, клиенты не могут напрямую обращаться к данным, доступ осуществляется при помощи указателей интерфейсов. Все интерфейсы всегда являются потомками базового ин- терфейса Iunknown. Указатель интерфейса - это 32-битный указатель на экземпляр объекта, который является, в свою очередь, указателем на реализацию 249 каждого метода интерфейса. Реализация методов доступна через мас- сив указателей на эти методы, который называется vtable. Использо- вание массива vtable похоже на механизм поддержки виртуальных функций в Object Pascal. СОМ-сервер представляет собой приложение или библиотеку, которая предоставляет услуги приложению-клиенту или библиотеке. СОМ-сервер содержит один или более СОМ-объектов, где СОМ- объекты выступают в качестве наборов свойств, методов и интерфей- сов. Клиенты не знают, как СОМ-объект выполняет свои действия. СОМ-объект предоставляет свои услуги при помощи интерфейсов. В дополнение, приложению-клиенту не нужно знать, где находится СОМ-объект. Технология СОМ обеспечивает прозрачный доступ независимо от местонахождения СОМ-объекта. Когда клиент запрашивает услугу от СОМ-объекта, он передает СОМ-объекту идентификатор класса (CLSID). CLSID - всего лишь GUID, который применяется при обращении к СОМ-объекту. После передачи CLSID, СОМ-сервер должен обеспечить так называемую фабрику класса (см. следующий раздел), которая создает экземпляры СОМ-объектов. В общих чертах, СОМ-сервер должен выполнять следующее: регистрировать данные в системном реестре Windows для связывания модуля сервера с идентификатором класса (CLSID); предоставлять фабрику СОМ-класса, создающую экзем- пляры СОМ-объектов; обеспечивать механизм, который выгружает из памяти серверы СОМ, которые в текущий момент времени не предоставляют услуг клиентам. СОМ-объекты представляют собой экземпляры coclass. Напом- ним, что Coclass - это класс, поддерживающий один или более интер- фейс. СОМ-объекты могут предоставлять только те услуги, которые определены в интерфейсах coclass. Экземпляры Coclass создаются при помощи специального типа объекта, называемого фабрикой клас- са. 250 Фабрика класса - это специальный СОМ-объект, который под- держивает интерфейс IclassFactory и отвечает за создание экземпля- ров того класса, с которым ассоциирована данная фабрика класса. Всякий раз, когда услуги СОМ-объекта запрашиваются клиен- том, фабрика класса создает и регистрирует экземпляр объекта для конкретного пользователя. Если услуга того же СОМ-объекта запра- шивает другой клиент, фабрика класса создает второй экземпляр объ- екта для обслуживания второго клиента. Coclass должен иметь фаб- рику класса и идентификатор класса CLSID. Использование CLSID для cociass подразумевает, что они могут быть откорректированы всякий раз, когда в класс вводятся новые интерфейсы. Таким образом, в отличие от DLL, новые интерфейсы могут изменять или добавлять методы, не влияя на старые версии. С использованием СОМ клиент не должен беспокоиться о том, где располагается объект, он просто делает вызов интерфейса данного объекта. Технология СОМ обеспечивает все необходимые шаги для того, чтобы сделать этот вызов. Шаги могут отличаться, в зависимо- сти от местонахождения объекта. Объект может находиться в том же процессе, где и клиент, в другом процессе на том же компьютере, где расположен клиент, или на другом компьютере в сети. В зависимости от этого применяются разные типы серверов: внутренний сервер (In-process server); локальный сервер или сервер вне процесса (Local server, Out-of-process server); удаленный сервер (Remote server). Внутренний сервер - это библиотека DLL, которая запущена в одном процессе вместе с клиентом. Приложение-клиент связывается с сервером внутри процесса при помощи прямых вызовов СОМ- интерфейса. Локальный СОМ-сервер регистрируется в системном реестре Windows так же, как и внутренний СОМ-сервер. Удаленный сервер - это библиотека DLL или иное приложение, запущенное на другом компьютере. То есть клиент и сервер работают на разных компьютерах в сети. 251 Удаленный сервер работает также с помощью прокси. Различие в работе между локальным и удаленным сервером заключается в типе используемой межпроцессной связи. В случае локального сервера - это СОМ, а в случае удаленного сервера - DCOM. Очень важным при разработке СОМ-приложений является со- здание приложений, называемых СОМ-клиентами, которые могут за- прашивать интерфейсы объектов, чтобы определить те услуги, кото- рые может предоставить СОМ-объект. Типичным СОМ-клиентом является диспетчер автоматизации (Automation Controller). Диспетчер автоматизации - это часть прило- жения, которая знает какой тип информации необходим ему от раз- ных объектов сервера, и она запрашивает данную информацию по мере надобности. |