Файл: Учебнопрактическое пособие Владимир 2021.pdf

282 общение готово к передаче, поэтому выполняется прерывание по вы- зову ядра.
Когда ядро получает управление, оно переключает контексты, сохраняет регистры процессора и карту памяти (дескрипторы стра- ниц), устанавливает новую карту памяти, которая будет использо- ваться для работы в режиме ядра.
Поскольку контексты ядра и пользователя различаются, ядро должно скопировать сообщение в свое собственное адресное про- странство, запомнить адрес назначения, после чего передать его сете- вому интерфейсу. На этом завершается работа на клиентской сто- роне. Включается таймер передачи, и ядро может либо выполнять циклический опрос наличия ответа, либо передать управление плани- ровщику, который выберет какой-либо другой процесс на выполне- ние. В первом случае ускоряется выполнение запроса, но отсутствует мультипрограммирование.
На стороне сервера поступающие биты помещаются принима- ющей аппаратурой либо во встроенный буфер, либо в оперативную память. Когда вся информация будет получена, генерируется преры- вание. Обработчик прерывания проверяет правильность данных па- кета и определяет, какому с табу следует их передать. Если ни один из стабов не ожидает этот пакет, обработчик должен либо поместить его в буфер, либо вообще отказаться от него. Если имеется ожидаю- щий стаб, то сообщение копируется ему. Наконец, выполняется пе- реключение контекстов, в результате чего восстанавливаются реги- стры и карта памяти, принимая те значения, которые они имели в мо- мент, когда стаб сделал вызов receive.

283
Рис. 5.2. Этапы выполнения процедуры RPC
Теперь начинает работу серверный стаб. Он распаковывает па- раметры и помещает их соответствующим образом в стек. По завер- шении работы, выполняется вызов сервера. После выполнения про- цедуры сервер передает результаты клиенту. Для этого выполняются все описанные выше этапы, только в обратном порядке.
Маршаллинг на примере COM/DCOM
Местонахождение сервера прозрачно для клиента, но не каса- лись вопроса о том, как эта прозрачность обеспечивается. Ведь, по сути дела, клиент вызывает методы, которые могут располагаться в адресном пространстве другого процесса или даже на удалённом компьютере. На самом деле методы, естественно, вызываются в ад- ресном пространстве сервера. На клиентской стороне собирается вся информация, необходимая для вызова метода, затем эти данные пере- даются серверу, расшифровываются, вызывается нужный метод с нужными параметрами, а результат передаётся клиенту в обратном порядке. Таким образом, задача вызова метода через границы процес- са разбивается на три части:

284

Сбор на стороне клиента всех необходимых для вызова данных и сериализация их в единый поток. Этот этап называется маршалингом (marshaling).

Передача сформированного потока через границы процес- са или по сети.

Извлечение на стороне сервера данных из потока и фор- мирование на их основе структур, которые затем будут переданы ме- тоду в качестве параметров. Этот этап называется обратным марша- лингом (unmarshaling).
Нередко под словом "маршалинг" объединяют все три этапа процесса, хотя это не совсем правильно.
Детальное знакомство с этапами вызова мы начнём со второго из них. Это единственный этап, на котором не учитывается специфи- ка вызываемого метода. Все действия системы на данном этапе сво- дятся к решению простой транспортной задачи: как передать поток заданной длины из адресного пространства клиента в адресное про- странство сервера. Эта задача решается специальными системными объектами, которые называются объектами канала. Объект канала на стороне клиента получает поток данных и передаёт его объекту кана- ла на стороне сервера. Передача осуществляется с помощью протоко- ла ORPC (Object Remote Procedure Call — вызов удалённых процедур объекта).
Разработчики COM/DCOM многое позаимствовали из стандарта
DCE RPC (Distributed Computing Environment Remote Procedure Call).
Этот стандарт, разработанный OSF (Open Software Foundation), пред- назначен для вызова процедур, реализованных на удалённом компью- тере. На нём основана такая широко известная модель как CORBA.
При вызове методов удалённого объекта объекты канала используют
RPC в чистом виде — как уже было сказано, специфика методов на данном этапе значения не имеет, поэтому RPC одинаково хорошо подходит для удалённого вызова как обычных процедур, так и мето- дов COM-объектов. При вызове методов локального сервера исполь- зуется разработанный Microsoft специально для COM/DCOM прото- кол LRPC (Lightweight RPC — облегчённый RPC), который близок к

285
RPC, но оптимизирован для передачи потока через общую область памяти, а не через сеть. Протоколы RPC и LRPC вместе называются
ORPC. Далее мы будем подробнее говорить о сетевом транспорте в
COM/DCOM, а пока остановимся на том, что чаще всего RPC для пе- редачи данных использует протокол TCP, хотя системные настройки позволяют использовать и другие протоколы. В любом случае ни клиент, ни сервер об этом не заботятся — система использует требу- емый транспортный протокол самостоятельно.
Теперь вернёмся к первому и третьему этапам — прямому и об- ратному маршалингу. Этим занимаются два специальных объекта — заместитель (proxy) и заглушка (stub). Заместитель загружается в ад- ресное пространство клиента. Упрощённо его можно рассматривать как специальный COM-объект, реализующий те же интерфейсы, что и тот объект, который клиент использует. Фактически, клиент работает с интерфейсами заместителя, а не самого объекта. Когда клиент дума- ет, что он вызывает метод COM-объекта, на самом деле он вызывает соответствующий метод заместителя. Заместитель, получив вызов, формирует поток, который следует отослать серверу, и передаёт его своему объекту канала. До этого момента данные передаются в пре- делах одного адресного пространства. Далее клиентский объект кана- ла, используя ORPC, передаёт поток серверному объекту, а тот — за- глушке (и серверный объект, и заглушка находятся в адресном про- странстве сервера). Заглушка извлекает данные из потока, восстанав- ливая их структуру, и вызывает соответствующий метод сервера. По- сле завершения этого метода результаты его работы передаются кли- енту по этой же цепочке, но в обратном порядке. Таким образом, для входных параметров метода прямой маршалинг выполняется заме- стителем, а обратный — заглушкой, а для выходных параметров — наоборот.
Использование заглушки и заместителя приводит к тому, что клиент всегда вызывает методы заместителя в своём адресном про- странстве, а сервер получает вызовы от заглушки также в своём ад- ресном пространстве. Процесс передачи данных из одного адресного пространства в другое невидим ни для сервера, ни для клиента.

286
Упаковка данных в поток и их последующее извлечение — не такая простая задача, как это может показаться на первый взгляд. Ос- новная проблема заключается в передаче параметров. С параметрами простых типов (Integer, Real, Boolean и т.п.) всё просто — они в нуж- ном порядке заносятся в поток и так же из него извлекаются. А вот с указателями так просто не получится: бессмысленно передавать в по- ток само значение указателя — в другом адресном пространстве оно не будет иметь никакого смысла. Нужно вставить в поток ту область памяти, на которую ссылается указатель. Для этого надо знать размер этой области. Кроме того, указатель может ссылаться на структуру, которая, в свою очередь, тоже может содержать указатели, которые также нужно передавать не по значению, а копировать в поток нуж- ную область памяти. Некоторые специфические типы (как, например,
BSTR) могут хранить данные и в области, находящейся по отрица- тельному смещению от указателя. Чтобы корректно упаковать все данные в поток, а затем извлечь их и восстановить их структуру, и за- глушка, и заместитель должны обладать исчерпывающей информаци- ей о всех типах данных, используемых параметрами. Кроме того, они должны знать, какие параметры являются входными и передаются от клиента серверу, а какие — выходными (от сервера клиенту). Оче- видно, что построение универсальных заместителя и заглушки, в рав- ной мере пригодных для всех интерфейсов, невозможно.
Существует три вида маршалинга, различающиеся тем, кто несёт ответственность за упаковку и распаковку данных:
1) Стандартный маршалинг. В этом случае заместитель и за- глушка создаются специальной динамически компонуемой библиоте- кой, которая так и называется — proxy/stub dll. Эта библиотека долж- на быть установлена и зарегистрирована как на серверном, так и на клиентском компьютере. Если сервер рассчитан на стандартный мар- шалинг, его разработчик должен также создать proxy/stub dll и рас- пространять её вместе со своим сервером. Некоторые среды разра- ботки позволяют автоматизировать построение proxy/stub dll на осно- ве формального описания интерфейсов. Delphi в число таких средств, к сожалению, не входит. Тем не менее, на Delphi можно разработать

287 сервер, ориентированный на стандартный маршалинг, хотя proxy/stub dll придётся создавать другими средствами. При стандартном марша- линге разработчик имеет большой выбор типов для параметров и мо- жет определять свои структуры.
2) Универсальный маршалинг. В этом случае заместитель и за- глушка реализуются стандартной системной библиотекой oleaut32.dll.
Для того, чтобы эта библиотека могла учесть особенности конкрет- ных интерфейсов, на клиентском и серверном компьютерах должна быть зарегистрирована т.н. библиотека типов, которую предоставляет разработчик сервера. Библиотека типов (type library) обычно пред- ставляет собой файл с расширением tlb, хранящий описание интер- фейсов (библиотеке типов будет посвящён следующий урок). Биб- лиотека типов может быть также включена в сам сервер (как во внут- ренний, так и во внешний), и тогда сервер становится самодостаточ- ным, никаких дополнительных файлов для работы с ним не требуется.
При использовании универсального маршалинга разрешёно исполь- зовать только VARIANT-совместимые типы.
3) Пользовательский маршалинг. В этом случае объект сам за- нимается упаковкой данных, реализуя стандартный интерфейс
IMarshal. Разработчик сервера при этом должен предоставить ориги- нальную библиотеку для создания заместителя в адресном простран- стве клиента, и этот заместитель также должен реализовывать интер- фейс IMarshal. В этом случае разработчик сервера получает возмож- ность не только управлять процессами прямого и обратного марша- линга, но и выбрать свой способ передачи данных, отказавшись от услуг стандартных объектов канала. Это позволяет, например, ис- пользовать нестандартный транспортный протокол или даже нестан- дартное физическое соединение при взаимодействии двух компьюте- ров. Мы не будем больше здесь останавливаться на пользовательском маршалинге, так как он достаточно сложен, а используется редко.

288
5.5. Сервис-ориентированная архитектура
Концепция СОА
По определению организации OASIS (Organization for the
Advancement
of
Structured
Information
Standards), сервис- ориентированная архитектура (Service-Oriented Architecture – SOA) – это парадигма организации и использования распределенных воз- можностей, которые могут принадлежать различным владельцам. В основе сервис-ориентированной архитектуры лежит сущность «дей- ствия» (в противоположность сущности «объекта» объектно- ориентированной архитектуры). Типичными составляющими сервис ориентированной архитектуры являются: сервисные компоненты
(сервисы); контракты сервисов (интерфейсы); соединители сервисов
(транспорт) и механизмы обнаружения сервисов (регистры).
Сервисные компоненты (или сервисы) описываются программ- ными компонентами, обеспечивающими прозрачную сетевую адреса- цию. Сервисами называются открытые, самоопределяющиеся компо- ненты, поддерживающие быстрое построение распределенных при- ложений. При этом нет четкого определения, какой объем услуг дол- жен предоставлять отдельный сервис. С одной стороны, мелкомо- дульный сервис может предоставлять элементарный объем функцио- нальной нагрузки и обеспечивать высокую степень повторного ис- пользования. В этом случае, для получения желаемого результата, необходимо обеспечить координированную работу нескольких серви- сов. С другой стороны, использование крупномодульных сервисов позволяет обеспечить хорошую инкапсуляцию функциональности, но затрудняет повторное использование таких сервисов, в связи с их уз- кой специализацией.
Контракт сервиса (или интерфейс) обеспечивает описание воз- можностей и качества предоставляемых услуг, предоставляемых кон- кретным сервисом. В интерфейсе определяется формат сообщений, используемый для обмена информацией, а также входные и выходные

289 параметры методов, поддерживаемых сервисным компонентом. От выбора языка и способа описания интерфейса зависят возможности программной совместимости различных реализаций сервис- ориентированной архитектуры.
Соединитель сервисов (или транспорт) обеспечивает обмен ин- формацией между отдельными сервисными компонентами. Наряду с открытыми стандартами описания интерфейсов, использование гиб- ких транспортных протоколов для обмена информацией между сер- висными компонентами позволяет повысить программную совмести- мость сервис-ориентированной системы.
Механизмы обнаружения сервисов (или регистры сервисов) ис- пользуются для поиска сервисных компонентов, обеспечивающих требуемую функциональность. Среди всего множества различных систем, обеспечивающих обнаружения сервисов, можно выделить две основных категории: системы динамического и статического обнару- жения. Статические системы обнаружения сервисов (например,
UDDI) ориентированы на хранение информации о сервисах в редко изменяющихся системах. Динамические системы обнаружения сер- висов ориентированы на системы, в которых допустимо частое появ- ление и исчезновение сервисных компонентов.
На сегодняшний день, веб-сервисы – это наиболее часто встре- чающейся реализация сервис-ориентированной архитектуры. Веб- сервисы – это технология, разработанная для поддержки взаимодей- ствия между распределенными системами посредством вычислитель- ной сетуя Веб-сервисы – это слабосвязанные программные компонен- ты, поддерживающие многократное использование, которые семан- тически инкапсулируют отдельные функциональные возможности и программным образом доступны по стандартным протоколам Интер- нета. Веб-сервисы– это независимая от платформы и языка програм- мирования среда, так как базируются на стандарте XML.
Большинство веб-сервисов используют HTTP для передачи со- общений. Это дает значительное преимущество при разработке рас- пределенных приложений в масштабе Интернет, так как обычно брандмауэры и прокси-серверы без проблем пропускают HTTP-

290 трафик, и в процессе взаимодействия не возникает неожиданных трудностей (которые могут возникнуть, например, при использовании технологии CORBA).
Принципы построения СОА
СОА не предписывает жесткой вертикальной («сверху вниз») методологии проектирования, внедрения или управления ИТ- инфраструктурой. Вместо этого, СОА ограничивается лишь рядом принципов, характеризующих каждый из этих процессов; поэтому ее иногда называют не архитектурой, а архитектурным стилем. Отметим некоторые из этих принципов.

Распределенное проектирование. Решения относительно внутренних особенностей информационных систем принимаются различными группами людей, имеющими собственные организаци- онные, политические и экономические мотивы.

Постоянство изменений. Отдельные участки архитектуры могут претерпевать изменения в любой момент времени.

Последовательное совершенствование. Локальное улуч- шение компонентов архитектуры должно приводить к совершенство- ванию всей архитектуры в целом – к росту суммарной полезности компонентов того же уровня, что и изменяемый, равно как и компо- нентов более низкого и более высокого уровня.

Рекурсивность. Однотипные решения имеют место на различных уровнях архитектуры.
С точки зрения информационных технологий, логика предприя- тия может быть разделена на две важных половины: бизнес-логика и логика приложения. Каждый слой существует в своем собственном
«мире».
Бизнес-логика является документальной реализацией бизнес- требований, которые исходят из проблемной области, в которой рабо- тает предприятие. Бизнес-логика, как правило, структурирована в процессах, которые выражают эти требования, а также ограничениях и зависимости от внешних влияний.

291
Логика приложения – это реализация бизнес-логики, организо- ванная на основе различных технологических решений. Логика при- ложения выражает процессы бизнес-логики посредством приобретен- ных или специально разработанных программных систем в условиях ограниченных технических возможностей и зависимостей от постав- щика решения.
Процесс преобразования бизнес-логики в логику приложений и реализация сервисов на основе данных требований является процес- сом создания сервисно-ориентированной инфраструктуры для задач предприятия. Не существует «догматических» принципов построе- ния СОА, но при реализации собственной инфраструктуры желатель- но придерживаться некоторых основных подходов, описанных ниже.
1. Сервисы должны поддерживать повторное использование.
СОА-системы должны поддерживать повторное использование всех сервисов, независимо от сиюминутных требований к их функцио- нальным особенностям. Если при разработке системы постараться максимально учесть это требование, то повышаются шансы значи- тельно упростить процесс решения задач, которые непременно по- явятся в будущем, при развитии системы. Также изначально ориен- тированный на повторное использование сервис позволяет избежать разработки «обертки», которая бы подстраивала старый сервис для решения новых задач.
Так как сервис– это не что иное, как просто набор связных опе- раций, логика каждой индивидуальной операции, предоставляемой сервисом, должна поддерживать повторное использование.
2. Сервисы должны обеспечивать формальный контракт ис- пользования.
Контракт сервиса предоставляет следующую информацию:

Конечную точку (service endpoint): адрес, по которому можно обратиться к данному сервису;

Все операции, предоставляемые сервисом;

Все сообщения, поддерживаемые каждой операцией;

Правила и характеристики сервиса и его операций.