Учебнопрактическое пособие Владимир 2021
 Скачать 7.94 Mb.
|
|
5.3.Технология inetd Понятие UNIX-подобных систем. UNIX (читается ю́никс) — семейство переносимых, многоза- дачных и многопользовательских операционных систем. Первая система UNIX была разработана в 1969 году в подраз- делении Bell Labs компании AT&T. С тех пор было создано большое количество различных UNIX-систем. Юридически лишь некоторые из них имеют полное право называться «UNIX»; остальные же, хотя и используют сходные концепции и технологии, объединяются терми- ном «UNIX-подобные» (англ. UNIX-like). Для краткости в данной статье под UNIX-системами подразумеваются как истинные UNIX, так и UNIX-подобные ОС. Некоторые отличительные признаки UNIX-систем включают в себя: Использование простых текстовых файлов для настройки и управления системой; Широкое применение утилит, запускаемых в командной строке; Взаимодействие с пользователем посредством виртуально- го устройства — терминала; Представление физических и виртуальных устройств и не- которых средств межпроцессового взаимодействия как файлов; 273 Использование конвейеров из нескольких программ, каж- дая из которых выполняет одну задачу. В настоящее время UNIX-системы используются в основном на серверах, а также как встроенные системы для различного оборудо- вания. На рынке ОС для рабочих станций и домашнего применения лидером является Microsoft Windows, UNIX занимает только второе (Mac OS X), третье (GNU/Linux) и многие последующие места. UNIX-системы имеют большую историческую важность, по- скольку благодаря им распространились некоторые популярные сего- дня концепции и подходы в области ОС и программного обеспечения. Также, в ходе разработки Unix-систем был создан язык Си. Среди примеров известных UNIX-подобных операционных си- стем: BSD, Solaris, Linux, Android, MeeGo, NeXTSTEP, Mac OS X, Apple iOS. UNIX-подобная операционная система (иногда сокр. *nix) — система, которая образовалась под влиянием UNIX. Термин включает свободные/открытые операционные системы, образованные от UNIX компании Bell Labs или эмулирующие его возможности, коммерче- ские и запатентованные разработки, а также версии, основанные на исходном коде UNIX. Нет стандарта, определяющего термин, и допу- стимы различные точки зрения о том, считать ли определённый про- дукт UNIX-подобным или нет. Деннис Ритчи, один из создателей UNIX, выразил своё мнение, что UNIX-подобные системы, такие как Linux, являются де-факто UNIX-системами. Эрик Рэймонд предложил разделить UNIX- подобные системы на 3 типа: Генетический UNIX Системы, исторически связанные с кодовой базой AT&T. Боль- шинство, но не все коммерческие дистрибутивы UNIX-систем попа- дают под эту категорию. Так же, как и BSD-системы, которые явля- ются результатами работы университета Беркли в поздних 1970-х и ранних 1980-х. В некоторых из этих систем отсутствует код AT&T, но до сих пор прослеживается происхождение от разработки AT&T. UNIX по товарному знаку, или бренду 274 Эти системы, в основном коммерческого характера, были опре- делены The Open Group как соответствующие Единой спецификации UNIX, и им разрешено носить имя UNIX. Большинство этих систем — коммерческие производные кодовой базы UNIX System V в той или иной форме (например, Amiga UNIX), хотя некоторые (например, z/OS компании IBM) заслужили торговую марку через слой совме- стимости с POSIX, не являясь по сути UNIX. Многие старые UNIX- системы не подходят под это определение. UNIX по функциональности В целом, любая система, поведение которой примерно соответ- ствует спецификации UNIX. К таким системам можно отнести Linux и Minix, которые ведут себя подобно UNIX-системе, но не имеют ге- нетических связей с кодовой базой AT&T. Большинство свобод- ных/открытых реализаций UNIX, являясь генетическим UNIX или нет, подпадают под ограниченное определение этой категории в связи с дороговизной сертификации The Open Group, которая стоит не- сколько тысяч долларов. Понятие фоновой службы Фо́новая зада́ча (фоновой процесс) — это процесс, который ра- ботает в фоне, на заднем плане. Имеется в виду, что оболочка опера- ционной системы, которая выполняет фоновый процесс, не ждёт за- вершения или окончания процесса, как это происходит с обычными программами. Оболочка может запустить ещё много процессов сразу после запуска одного фонового так, что они будут выполняться одно- временно. На самом деле процессы будут выполняться поочерёдно то один, то другой, но скорость переключения между процессами слиш- ком быстра для человеческого восприятия, поэтому нам кажется, что они выполняются одновременно. Типичными фоновыми процессами, выполняющимися в системе, являются обработчики событий и си- стемные службы. В рамках выделенной оперативной памяти может выполняться любое желаемое количество процессов. 275 Как правило (например, в UNIX), деление процессов на фоно- вые и процессы переднего плана отражает только отношение процес- са к оболочке ОС и к драйверу терминала, а не особенности его ис- полнения внутри операционной среды и диспетчера. Так, например, фоновый процесс, как правило, не имеет права принимать ввод пользователя, при попытке сделать это он останавли- вается и оболочка ОС выводит об этом сообщение пользователю. Оболочка ОС UNIX подразделяет запущенные ей группы про- цессов на «переднего плана», «фоновые» и «приостановленные», и поддерживает перевод групп процессов из одного из выше названных классов в другой. Для этого используется & (амперсенд) в конце ко- мандной строки, клавиатурная комбинация Ctrl-Z (приостанавливает текущую группу процессов переднего плана), и команды jobs, fg и bg. Отличие фоновых процессов от «демонов» (служб) ОС UNIX в том, что «демон» полностью утрачивает ассоциацию с пользователь- ским терминалом и оболочкой ОС, зачастую продолжая существовать и после выхода породившего его процесса оболочки. Фоновый же процесс по-прежнему сохраняет логическую ассоциацию с термина- лом и оболочкой. Демон inetd управляет другими демонами. Он запускает демо- ны-клиенты, когда для них есть работа, а после выполнения задачи позволяет им тихо завершиться. Демон inetd работает только с теми демонами, которые оказы- вают услуги по сети. Для того чтобы установить, не пытается ли кто- нибудь получить доступ к одному из его клиентов, демон inetd кон- тролирует те редко активизируемые сетевые порты, которые обслу- живаются обычно бездельничающими демонами. Когда устанавлива- ется соединение, демон inetd запускает соответствующий демон и со- единяет каналы его стандартного ввода-вывода с сетевым портом. Это правило следует учитывать при написании демонов, совмести- мых с inetd. Работа некоторых демонов (например, тех, что связаны с NIS и NFS) основана на протоколе RPC, который был разработан и реализо- ван компанией Sun в качестве механизма совместного использования 276 информации в распределенной сетевой среде. Назначениями портов для RPC-демонов управляет демон portmap (иногда называется rpcbind). Многие демоны могут использоваться либо традиционным спо- собом (т.е. они запускаются однократно и работают до выключения системы), либо под контролем демона inetd. Одной из распространённых задач администрирования является запуск каких-то задач в определённое время с заданной периодично- стью. В UNIX этой цели служит планировщик заданий cron. За выполнением задач по расписанию следит демон, который обычно называется crond. Само расписание описывается в специаль- ных конфигурационных файлах — есть расписание общесистемных задач (/etc/crontab), а также персональное расписание задач (файл crontab) для каждого пользователя. Всем ли пользователям дозволяет- ся пользоваться выполнением задач по расписанию — определяет ад- министратор системы; зачастую для этого пользователей включают в специальную группу (например, cron). Стандартные потоки ввода и вывода в UNIX/Linux наряду с файлами являются одним из наиболее распространённых средств для обмена информацией процессов с внешним миром, а перенаправле- ния >, >> и |, одной из самых популярных конструкций командного интерпретатора. Процесс взаимодействия с пользователем выполняется в терми- нах записи и чтения в файл. То есть вывод на экран представляется как запись в файл, а ввод — как чтение файла. Файл, из которого осуществляется чтение, называется стандартным потоком ввода, а в который осуществляется запись — стандартным потоком вывода. Стандартные потоки — воображаемые файлы, позволяющие осуществлять взаимодействие с пользователем как чтение и запись в файл. Кроме потоков ввода и вывода, существует еще и стандартный поток ошибок, на который выводятся все сообщения об ошибках и те информативные сообщения о ходе работы программы, которые не могут быть выведены в стандартный поток вывода. 277 Вывод данных на экран и чтение их с клавиатуры происходит потому, что по умолчанию стандартные потоки ассоциированы с тер- миналом пользователя. Это не является обязательным — потоки можно подключать к чему угодно — к файлам, программам и даже устройствам. В командном интерпретаторе bash такая операция назы- вается перенаправлением. Стандартные потоки можно перенаправлять не только в файлы, но и на вход других программ. Если поток вывода одной программы соединить с потоком ввода другой программы, получится конструк- ция, называемая каналом, конвейером или пайпом (от англ. pipe, тру- ба). В bash канал выглядит как последовательность команд, отде- ленных друг от друга символом |: команда1 | команда2 | команда3 ... Стандартный поток вывода команды1 подключается к стан- дартному потоку ввода команды2, стандартный поток вывода коман- ды2 в свою очередь подключается к потоку ввода команды3 и т.д. В UNIX/Linux существует целый класс команд, предназначен- ных для преобразования потоков данных в каналах. Такие программы известны как фильтры. Программа-фильтр читает данные, поступаю- щие со стандартного потока ввода (на вход), преобразовывает их тре- буемым образом и выводит на стандартный поток вывода (на выход). Существует множество хорошо известных фильтров, призванных ре- шать определенные задачи, и являющихся незаменимым инструмен- том в руках пользователя ОС. Каналы в ОС Linux являются одной из наиболее часто применя- емых конструкций, а фильтры — наиболее часто применяемых про- грамм. Большинство повседневных задач в Linux легко решаются при помощи конструкций построенных на основе нескольких фильтров. Программы, образующие канал, выполняются параллельно как независимые процессы. В UNIX/Linux существует целый класс команд, которые прини- мают данные со стандартного потока ввода, каким-то образом обра- 278 батывают их, и выдают результат на стандартный поток вывода. Та- кие программы называются программами-фильтрами. Как правило, все эти программы работают как фильтры, если у них нет аргументов (опции могут быть), но как только им в качестве аргумента передаётся файл, они считывают данные из этого файла, а не со стандартного потока ввода (существуют и исключения, напри- мер, программа tr, которая обрабатывает данные поступающие ис- ключительно через стандартный поток ввода). 5.4. Технология RPC Удалённый вызов процедур (или Вызов удалённых процедур) (от англ. Remote Procedure Call (RPC)) — класс технологий, позволя- ющих компьютерным программам вызывать функции или процедуры в другом адресном пространстве (как правило, на удалённых компью- терах). Обычно, реализация RPC технологии включает в себя два компонента: сетевой протокол для обмена в режиме клиент-сервер и язык сериализации объектов (или структур, для необъектных RPC). Различные реализации RPC имеют очень отличающуюся друг от дру- га архитектуру и разнятся в своих возможностях: одни реализуют ар- хитектуру SOA, другие CORBA или DCOM. На транспортном уровне RPC используют в основном протоколы TCP и UDP, однако, некото- рые построены на основе HTTP (что нарушает архитектуру ISO/OSI, так как HTTP изначально не транспортный протокол). Реализация технологии. Идея вызова удаленных процедур. Идея вызова удалённых процедур (Remote Procedure Call — RPC) состоит в расширении хорошо известного и понятного меха- низма передачи управления и данных внутри программы, выполняю- щейся на одной машине, на передачу управления и данных через сеть. Средства удалённого вызова процедур предназначены для облегчения организации распределённых вычислений и создания распределенных клиент-серверных информационных систем. Наибольшая эффектив- 279 ность использования RPC достигается в тех приложениях, в которых существует интерактивная связь между удалёнными компонентами с небольшим временем ответов и относительно малым количеством пе- редаваемых данных. Такие приложения называются RPC- ориентированными. Характерными чертами вызова удалённых процедур являются: Асимметричность, то есть одна из взаимодействующих сторон является инициатором; Синхронность, то есть выполнение вызывающей процеду- ры приостанавливается с момента выдачи запроса и возобновляется только после возврата из вызываемой процедуры. Реализация удалённых вызовов существенно сложнее реализа- ции вызовов локальных процедур. Можно обозначить следующие проблемы и задачи, которые необходимо решить при реализации RPC: Так как вызывающая и вызываемая процедуры выполняются на разных машинах, то они имеют разные адресные пространства, и это создает проблемы при передаче параметров и результатов, особенно если машины находятся под управлением различных операционных систем или имеют различную архитектуру (например, используется прямой или обратный порядок байтов). Так как RPC не может рассчи- тывать на разделяемую память, то это означает, что параметры RPC не должны содержать указателей на ячейки нестековой памяти и что значения параметров должны копироваться с одного компьютера на другой. Для копирования параметров процедуры и результата выпол- нения через сеть выполняется их сериализация. В отличие от локального вызова удалённый вызов процедур обязательно использует транспортный уровень сетевой архитектуры (например TCP), однако это остается скрытым от разработчика. Выполнение вызывающей программы и вызываемой локальной процедуры в одной машине реализуется в рамках единого процесса. Но в реализации RPC участвуют как минимум два процесса — по од- ному в каждой машине. В случае, если один из них аварийно завер- шится, могут возникнуть следующие ситуации: при аварии вызыва- 280 ющей процедуры удалённо вызванные процедуры станут «осиротев- шими», а при аварийном завершении удалённых процедур станут «обездоленными родителями» вызывающие процедуры, которые бу- дут безрезультатно ожидать ответа от удалённых процедур. Существует ряд проблем, связанных с неоднородностью языков программирования и операционных сред: структуры данных и струк- туры вызова процедур, поддерживаемые в каком-либо одном языке программирования, не поддерживаются точно так же во всех других языках. Таким образом имеется проблема совместимости, до сих пор не решённая ни с помощью введения одного общепринятого стандар- та, ни с помощью реализации нескольких конкурирующих стандартов на всех архитектурах и во всех языках. Существуют множество технологий, обеспечивающих RPC: Sun RPC (бинарный протокол на базе TCP и UDP и XDR) RFC-1831 второе название ONC RPC RFC-1833 .NET Remoting (бинарный протокол на базе TCP, UDP, HTTP) SOAP — Simple Object Access Protocol (текстовый прото- кол на базе HTTP) см. спецификацию: RFC-4227 XML RPC (текстовый протокол на базе HTTP) см. специ- фикацию: RFC-3529 Java RMI — Java Remote Method Invocation — см. специ- фикацию: http://java.sun.com/j2se/1.5.0/docs/guide/rmi/index.html JSON-RPC— JavaScript Object Notation Remote Procedure Calls (текстовый протокол на базе HTTP) см. спецификацию: RFC- 4627 DCE/RPC — Distributed Computing Environment / Remote Procedure Calls (бинарный протокол на базе различных транспортных протоколов, в том числе TCP/IP и Named Pipes из протокола SMB/CIFS) DCOM — Distributed Component Object Model известный как MSRPC Microsoft Remote Procedure Call или «Network OLE» (объ- ектно-ориентированное расширение DCE RPC, позволяющее переда- 281 вать ссылки на объекты и вызывать методы объектов через таковые ссылки) Routix.RPC ZeroC ICE. Взаимодействие программных компонентов при выполнении удаленного вызова процедуры иллюстрируется рисунком 5.1. Рис. 5.1. Порядок удаленного вызова процедуры. После того, как клиентский стаб был вызван программой- клиентом, его первой задачей является заполнение буфера отправляе- мым сообщением. В некоторых системах клиентский стаб имеет единственный буфер фиксированной длины, заполняемый каждый раз с самого начала при поступлении каждого нового запроса. В других системах буфер сообщения представляет собой пул буферов для от- дельных полей сообщения, причем некоторые из этих буферов уже заполнены. Этот метод особенно подходит для тех случаев, когда па- кет имеет формат, состоящий из большого числа полей, но значения многих из этих полей не меняются от вызова к вызову. Затем параметры должны быть преобразованы в соответствую- щий формат и вставлены в буфер сообщения. К этому моменту со- 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): адрес, по которому можно обратиться к данному сервису; Все операции, предоставляемые сервисом; Все сообщения, поддерживаемые каждой операцией; Правила и характеристики сервиса и его операций. 292 3. Сервисы должны быть слабосвязаны. Никто не может преду- гадать, в какую сторону будет развиваться IT-инфраструктура. Реше- ния могут развиваться, взаимодействовать, заменять друг друга. В связи с этим основной задачей является сохранение целостности си- стемы в рамках такого развития, независимо от происходящих изме- нений. Система сервисов является слабосвязанной, если сервис может приобретать знания о другом сервисе, оставаясь независимым от внутренней реализации логики данного сервиса. Это достигается по- средством использования контрактов сервисов. Слабосвязанность программных компонентов, лежащая в осно- ве СОА, позволяет значительно упростить координацию распреде- ленных систем и их реконфигурацию. Основная цель использования концепции слабосвязанных программных систем – это уменьшение количества зависимостей между компонентами. При уменьшении количества связей, уменьшается объем возможных последствий, воз- никающих в связи со сбоями или системными изменениями. Слабосвязанность – это не синоним «инкапсуляции» объектно- ориентированной концепции построения программных систем. Про- граммная система может полностью соответствовать требованиям инкапсуляции, но быть сильносвязанной на семантическом уровне. 4. Сервисы должны абстрагировать внутреннюю логику. Каж- дый сервис должен действовать как «черный ящик», скрывающий свои детали от окружающего мира. Нет четкого определения, какой объем логики должен помещаться в отдельном сервисе. Взаимодей- ствие на уровне интерфейсов является одним из требований для обес- печения слабой связанности. 5. Сервисы должны быть совместимы. Сервис может как са- мостоятельно реализовывать логику, так и применять другие сервисы для ее реализации. Сервисы должны быть спроектированы таким об- разом, чтобы поддерживать возможность их использования в качестве элементов другого сервиса. Принцип совместимости не зависит от того, использует ли сервис для выполнения своей работы другие сер- висы. 293 В качестве примера такого взаимодействия сервисов выступает концепция оркестрации сервисов. В этом случае, сервис- ориентированный процесс (который в принципе может быть опреде- лен как композиция сервисов) управляется сервисом родительского процесса, который включает в себя другие сервисы, являющиеся участниками данного процесса. Кроме того, принцип совместимости также определяет вид сер- висных операций. Совместимость– это, по сути, просто другая форма повторного использования, и поэтому операции должны быть стан- дартными, а для наибольшей совместимости должны обладать необ- ходимым уровнем детализации. 6. Сервисы должны быть автономными. Свойство автономно- сти требует, чтобы область бизнес-логики и ресурсов, используемых сервисом были ограничены явными пределами. Это позволяет серви- су самому управлять всеми своими процессами. Также это устраняет зависимость от других сервисов, что освобождает сервис от связей, которые могут препятствовать его применению и развитию. Вопрос автономности – наиболее важный аргумент при распределении биз- нес-логики на отдельные сервисы. Автономность не обязательно предоставляет сервису исключи- тельное право собственности на бизнес-логику, которую он инкапсу- лирует. Есть только гарантия того, что во время исполнения сервис контролирует любую логику, которую он реализует. Поэтому мы можем выделить два типами автономности: Автономность на уровне сервиса: границы ответственно- сти сервисов отделены, но они могут использовать общие ресурсы. Например, сервис обертки, который инкапсулирует унаследованную программную систему, которая также кем-то используется (незави- симо от данного сервиса), обладает автономностью данного типа. Он управляет унаследованной системой, но также совместно использует ресурсы с другими существующими клиентами. Чистая автономность: бизнес-логика и ресурсы находятся под полным контролем сервиса. Как правило, такой вид автономно- 294 сти используется, когда для реализации сервиса бизнес-логика созда- ется с нуля. 7. Сервисы не должны использовать информацию о состоянии. Сервисы должны сводить к минимуму объем информации о состоя- нии, и время, в течение которого они ею обладают. Информация о состоянии– это определенные данные, характеризующие текущую де- ятельность. Например, пока сервис обрабатывает сообщение, он вре- менно зависит от состояния (stateful). Если сервис несет ответствен- ность за сохранение состояния в течение более длительного времени, его способность оставаться доступным для других клиентов будет за- труднена. Независимость от состояния(statelessness) позволяет повысить возможности масштабируемости и повторного использования сер- висов. Чтобы сервис как можно меньше зависел от состояния, его операции должны быть разработаны с учетом соображений обработки информации без данных о состоянии. Основной особенностью СОА, поддерживающей независимость от состояния, является использование сообщений-документов. Чем выше сложность сообщения, тем более независимым и самодостаточ- ным оно остается. 8. Сервисы должны поддерживать обнаружение. Обнаружение сервисов позволяет избежать случайного создания избыточного сер- виса, обеспечивающего избыточную логику. Метаданные сервиса должны подробно описать не только общую цель сервиса, но и функ- циональность, реализуемую его операциями. На уровне СОА, обнаружение характеризует способность архи- тектуры обеспечить механизмы поиска, такие как реестр или каталог. На уровне сервиса, принцип обнаружения относится к процессу про- ектирования отдельного сервиса, так чтобы данный сервис настолько подавался обнаружению, насколько это возможно. 295 Веб-сервисы. XML Веб-сервисы (Веб-службы) – это программные компонен- ты, с помощью которых можно создавать независимые масштабируе- мые слабосвязанные приложения. В основе технологии веб-сервисов лежит процесс обмена сооб- щениями в формате XML-документов. Передача сообщений проис- ходит с использованием протоколов HTTP, XML, XSD, SOAP, WSDL, UDDI. Спецификация определяет три основных стандарта, используе- мых для поддержки представления, поиска и обмена информацией между веб-сервисами – это WSDL, UDDI и SOAP, образующие так называемый «треугольник СОА». Процесс взаимодействия между клиентом и поставщиком веб- сервиса представлен на рисунке 5.3. Рис. 5.3. Процесс взаимодействия между клиентом и поставщиком веб-сервиса Протокол SOAP предназначен для организации взаимодействия удаленных систем при помощи асинхронного обмена XML- отформатированными документами, состоящими из трех частей: кон- верта (обертки), заголовка и тела. SOAP формирует базовый слой стека протоколов веб-сервисов, обеспечивая инфраструктуру обмена сообщениями между ними. SOAP (Simple Object Access Protocol) – простой протокол досту- па к объектам. SOAP – это протокол для обмена информацией в рас- 296 пределенной системе. SOAP использует XML для определения обо- лочки структуры сообщения. Такая оболочка независима от семанти- ки реализации. SOAP определяет метод передачи сообщения из одной точки распределенной информационной системы в другую. Это возможно благодаря оболочке обмена сообщениями на основе XML, которая является независимой от модели программирования и наращиваемой, а также она может использоваться различными сетевыми протокола- ми. Одной из особенностей SOAP является использование его в лю- бом транспортном протоколе, например: TCP, HTTP, SMTP. Для того, чтобы поддерживать взаимодействие в SOAP определены взаимосвя- зи со стандартными протоколами. Таким образом, SOAP обеспечива- ет гибкую оболочку для взаимосвязи различных протоколов, а также реализует явное связывание для HTTP. Другая характеристика– это независимость от модели програм- мирования. Здесь можно выделить следующее: SOAP является раз- решенным для всех моделей программирования и не зависит от RPC (удаленный вызов процедур). В SOAP определена модель обработки однонаправленных со- общений. Все множество сообщений возможно объединить в общий процесс обмена сообщениями. Но возникают ситуации, когда получа- телю необходимо послать отправителю ответ. С помощью SOAP можно реализовать любое количество схем обмена сообщениями, и схема «запрос-ответ» одна из них. Для обмена сообщениями SOAP может использовать различные протоколы, т.к. оболочка SOAP-сообщения не зависит от протокола. В стандартном взаимодействии протоколов уже определены правила, по которым SOAP-сообщение передается от отправителя получателю, т.е. подобное взаимодействие описывает возможность согласовать SOAP и другой протокол, в котором описана собственная оболочка сообщения и, возможно, отличными от SOAP заголовками. SOAP взаимодействует с различными базовыми протоколами, такими как: HTTP, TCP, SMTP и некоторыми другими. 297 Благодаря этим характеристикам SOAP используется в тех рас- пределенных системах, в которых ранее обмен данными был труден или невозможен. Для того чтобы приложение могло использовать Web-сервис, необходимо детальное описание интерфейса взаимодействия. Для описания интерфейсов взаимодействия был предложен WSDL (Web Services Description Language) – это язык для описания Web-сервисов. В основе языка WSDL лежит XML. Язык WSDL (Web Services Description Language) описывает сер- висы в виде неких абстрактных ресурсов, способных принимать на вход документы определенных типов и инициировать отправление документов других типов. WSDL используется для описания веб- сервисов и для определения их расположения. WSDL определяет сер- вис с двух точек зрения: абстрактной и конкретной. На абстрактном уровне сервис задается в терминах посылаемых и принимаемых им сообщений, которые описываются средствами XML Schema в виде, независимом от конкретного транспортного про- токола. На конкретном уровне определяются привязки к транспорт- ным форматам и точкам физического размещения. Для описания интерфейса в WSDL-документ может входить различная информация, например, возможные операции, протокол взаимодействия и др. Обычно в документе WSDL можно выделить три логические части: Раздел определения типов данных– в данном разделе определяется вид XML-сообщений; Раздел абстрактных операции – здесь указывается список операций, которые возможно производить с сообщениями; Раздел для связывания сервисов – в этом разделе указыва- ется метод, которым сообщение доставляется. Протокол UDDI (Universal Description Discovery & Integration) представляет собой стандарт на внутреннее устройство и внешние интерфейсы базы данных (репозитория), хранящей описания серви- сов. Все описания в БД хранятся в виде XML-записей. Последняя версия UDDI обеспечивает репликацию репозиториев со сложными 298 моделями их подчиненности друг другу, построение репозитория из нескольких узлов (и репликацию данных между ними), глобальную уникальность записей и ключей, API публикации описаний и подпис- ки на изменения, средства обеспечения целостности данных, интер- национализации записей, шифрования содержимого. В то время как версия UDDI 2.0 предназначалась для поддержки каталогов элек- тронного бизнеса, версия 3.0 ориентирована и на внутрикорпоратив- ное использование для построения корпоративных систем в рамках идеологии сервис-ориентированной архитектуры. Поэтому она до- пускает создание реестров нескольких типов (общедоступный, част- ный и с разделяемым доступом). |