Рис Физический и логический обмен данными по сети 21 Рис Ахитектура процессов в распределенных системах
| Вид материала | Документы |
СодержаниеВызов методов Объекты, имеющие состояние Составные Типы данных Адресация объектов Cobol (1999 – Douglas Schmidt Steve Vinoski Основные элементы распределенной системы в технологии CORBA. |
- 7 Гробница и зодиак Сети I на рис 22 и рис. Ц31 представлен еще один зодиак того, 300.69kb.
- Для того чтобы проверить соединение с Интернет необходимо нажать на кнопку (см рис., 28.68kb.
- Важный параллелизм между русью-ордой и "западно-европейскими" габсбургами-новгородцами, 634.16kb.
- Урок информатики. Тема урока: Локальные и глобальные компьютерные сети. Обмен данными, 10.5kb.
- И. Д. Салмин московский инженерно-физический институт (государственный университет), 24.9kb.
- С. Н. Лукин Краткое практическое руководство, 296.48kb.
- Эксперимент – судья теории канарёв, 132.05kb.
- Рис. Сферы взаимодействия психики и личности (Управляющей психики) Рис., 2.3kb.
- Информационные услуги сети Интернет Ресурс, 111.01kb.
- При хронологическом сдвиге на 1800 лет, 684.4kb.
| Часть из указанных процедур реализуется только программно, другая часть – аппаратно, а какие-то операции могут выполняться как программами, так и аппаратурой. Место компонент РВС в модели ISO/OSI (Open System Interconnection), 1977
ARPAnet BBN's proposal followed Roberts' plan closely; it called for the network to be composed of small computers known as Interface Message Processors (more commonly known as IMPs). The IMPs at each site performed store-and-forward packet switching functions, and were connected to each other using modems connected to leased lines (initially running at 50 kbit/second). Host computers connected to the IMPs via custom bit-serial interfaces to connect to ARPAnet (Advanced Research Projects Agency Network).
Здесь важно то, что вызов процедуры (метода) обязательно сопровождается формированием некоторой структуры данных (здесь – на стеке) и передаче этой структуры (или иной информации, достаточной для ее обнаружения) другому фрагменту исполняемого кода. Нарисовать серверный/клиентский фрагменты процессов, каркасы/представители процедуры (выполняют манипуляции с кучей/стеком «имитируя» локальный вызов маршаЛ(!)инг/демаршаЛ(!)инг Указанные выше технологии различаются деталями и терминологией. Тем не менее, все они имеют много общего. В этом разделе мы попытаемся указать набор типовых элементов, которые в той или иной форме присутствуют в любой распределенной системе. Основными понятиями здесь являются:
Процессом принято называть тот поток команд, который рассматривается операционной системой как отдельная программа (или приложение) и выполняется в своем адресном пространстве. Эти процессы представляют собой среду, в которой функционируют фрагменты распределенной системы. Сами процессы могут быть многопоточными, но это уже зависит от деталей реализации (возможностей используемых языков программирования и операционных систем). При этом возможны довольно сложные ситуации. Например, фрагменты распределенной системы могут быть реализованы в форме Java-апплетов. В этом случае процессом будет являться тот экземпляр браузера (в комбинации с Java-машиной - средой исполнения Java-классов апплета), который загрузил соответствующий HTML-документ. Функциональность распределенной системы реализована в специальных фрагментах программного кода - сервисах, - которые отвечают за выполнение четко определенного списка операций (методов). Описание этих операций содержится в интерфейсах, которые представляют собой спецификации (списки аргументов с указанием типа передаваемых параметров, типы возвращаемых значений), не зависящие от деталей реализации. Процессы, в которых функционируют сервисы, принято называть серверными. Процессы, из которых идет обращение к сервисам (вызовы методов), принято называть клиентскими. Однако, четкого разделения по этому признаку не существует, т.к. могут существовать «смешанные» процессы, в которых наряду с функционированием собственных сервисов предусмотрены обращения к сервисам других процессов. Учитывая это замечание, правильнее говорить о клиентских и серверных фрагментах кода процессов в распределенной системе. Архитектура процессов в распределенных системах представлена на рисунке 
Вызов методов сервисов из клиентских фрагментов кода обеспечивается представителями интерфейсов. Это специально оформленные участки клиентского кода, которые обеспечивают передачу параметров вызываемым методам сервисов и возврат результатов таких вызовов, как если бы речь шла о клиентском вызове обычных методов в классических (не распределенных) приложениях. Достигается это за счет того, что представители интерфейсов содержат описание методов, спецификации которых абсолютно идентичны спецификациям соответствующих методов сервисов, и это гарантирует корректный вызов. Важно подчеркнуть, что, несмотря на совпадение спецификаций, функциональности этих двух категорий методов кардинально различаются: методы сервисов непосредственно обслуживают запросы клиентов, в то время как методы представителей интерфейсов реализуют системные функции, связанные с доставкой этих клиентских вызовов в другие процессы и возвратом результатов. Методы представителей интерфейсов далее называются предоставленными методами. Стандартизованный доступ к сервисам требует, чтобы серверные фрагменты кода включали в себя каркасы интерфейсов. Основная задача каркасов - направить полученный вызов нужному методу сервиса. В серверных фрагментах кода такой вызов происходит как обычный вызов внутренней процедуры. Однако, поскольку он является отражением соответствующего вызова в клиентском процессе, мы будем называть его доставленным вызовом. И, наконец, связующее ПО (middleware). Этот термин объединяет набор готовых программных компонентов, отвечающих за удаленное взаимодействие процессов. Именно эти компоненты обеспечивают прозрачность сети, передают вызовы между представителями интерфейсов и серверными фрагментами кода и возвращают результат клиентским фрагментам кода. Например, вызов предоставленного метода в клиентском процессе обрабатывается компонентами СПО и преобразуется в форму, пригодную для передачи его по сети. Эта процедура называется маршалингом (marshaling) вызова. Процессы взаимодействия с уровнем сетевых протоколов - также функция СПО. На стороне серверного процесса соответствующие компоненты СПО принимают вызов, поступивший в форме пакета данных (указатель конкретного сервиса, метода его интерфейса со списком значений аргументов), и преобразуют его в доставленный вызов метода сервиса. Это преобразование, обратное маршалингу, называют демаршалингом. Реализацией связующего ПО могут быть динамические библиотеки (*.DLL на платформах Microsoft, *.SO на платформах Unix или Linux), исполняемые модули *.EXE, а также файлы Java-кода *.CLASS или *.JAR. Функционирование СПО тоже происходит распределенным образом (см. ). Фрагменты кода СПО подгружаются во время запуска процессов, в которых функционируют фрагменты распределенной системы. Кроме того, часть СПО может присутствовать в форме специальных служб, запущенных на серверах - узлах сетей различного уровня. При этом функциональные возможности этих служб представлены специальными сервисами, реализующими стандартные (описанные в спецификациях СПО) интерфейсы. Доступ к этим стандартным сервисам из клиентских фрагментов кода происходит точно так же, как и к любым другим сервисам - через соответствующих представителей интерфейсов. 
Таким образом, современные архитектуры распределенных систем обобщают традиционную клиент-серверную схему сетевого взаимодействия в направлении, как принято говорить, многозвенных (multi-tire) систем, где разделение клиентских и серверных частей имеет место не на уровне процессов, а на уровне отдельных фрагментов кода. При этом место процессов серверов занимают фрагменты кода, реализующие сервисы, а место процессов клиентов - участки кода, где происходят удаленные (через сеть) вызовы методов сервисов.
Нужно сказать о двух модификациях асинхронного вызова:
Лекция 5 Продолжение RPC (от удаленных процедур – к удаленным объектам)
Все современные стандарты ППО, в той или иной мере, следуют принципам ООП. (Нарисовать молекулу) Черные кружочки - объекты или экземпляры типов. Тип - набор методов, которые может выполнять объект этого типа. Т.е. можно сказать, ТИП = ИНТЕРФЕЙС Пример. Тип калькулятор (на некотором «абстрактном» языке описания интерфейсов) Calc { add(float x, float y):float; // x + y mult(float x, float y): float; // x * y div(float x, float y): float; // x / y } CalcExt extends Calc { sub(float x, float y): float // x - y } - умеет делать все, что и Calc, и КТОМУ ЖЕ - вычитать. Вызов метода - часто называют «заявкой»/объектный вызов или заявка. Обычно всегда - это структура типа: {ссылка, содержимое} При вызове метода могут возникнуть «ИСКЛЮЧЕНИЯ», например, для нашего Calc, такое исключение возникнет, если второй аргумент y=0. exception DivideByZero {}; Calc { … div(float x, float y): {float | DivideByZero} // либо результат, либо – исключение } Лекция 6 Продолжение описания общих требований к ООA.
CalcPersist extends Calc { setMem(float x): void; // Запомнить x в буфере объекта getMem(): float; // Вернуть значение из буфера clearMem(): void; // Очистить буфер addMem(float x): void; multMem(float x): void; … } Работая с экземплярам такого типа следует помнить, что он имеет состояние, которое зависти от предыстории вызванных на нем операций
Использованный тип float относится к примитивным типам (int, double, string, …) поддержка таких типов естественна. Однако всегда удобно иметь возможность определять и использовать составные сложные типы данных. Например, для целей вычислений удобно использовать тип вектор, матрица и т.п. type FloatVector {float}* // последовательность из нескольких float. Здесь я «пытаюсь» использовать нотацию EBNF НЕ ПРИДИРАЙТЕСЬ exception CheckDimensions {}; CalcVector extends CalcExt { scalarProduct(FloatVector x, FloatVector y) {float | CheckDimensions}; } Более сложный пример. Объединение. Например, наш калькулятор умеет работать только с float. Но ведь есть еще double, int. Чтобы не плодить методы удобно было бы задавать «объединение» типов, которое могло бы принимать значение одного из указанного набора примитивных типов: type Number {int | float | double | string} // Поскольку для строки не все операции можно корректно задать надо бы предусмотреть исключение типа Unsupported exception Unsupported{string message} SuperCalc { add(Number x, Number y):Number; // x + y mult(Number x, Number y): {Number | Unsupported }; // x * y div(Number x, Number y): {Number | Unsupported}; // x / y } Таким образом от современных ППО можно требовать возможности определение различных типов данных и типов объектов (интерфейсов, описание которых основано на описаниях типов) И вот ВСЕ ЭТО нужно уметь делать на РАЗНЫХ ПЛАТФОРМАХ, и РАЗНЫХ ЯЗЫКАХ
Когда тип объекта задан, его нужно создать, затем уметь его обнаружить в сети: указать его ссылку. Ссылка - это всегда, { <сетевой адрес, для используемого транспорта, например хост, порт>, доп. идентификатор объекта (т.к. несколько объектов могут обслуживаться одним портом), тип объекта} ссылка скрыта (для WS) corbaloc:iiop:some.com:30000/someObjKey (для CORBA)
CORBA (Common Object Request Broker Architecture) является спецификацией создания распределенных программных систем, развиваемой консорциумом OMG (Object Management Group, ссылка скрыта ) - некоммерческой организацией, включающей в период «расцвета» более 800 компаний. В настоящее время в списке – 438 компаний, из которых более 100 университетов. Многие известные крупные разработчики ПО «уровня предприятия» (SAP_AG, IONA, Prism Technologies). Лидерами OMG являются фирмы Oracle, IBM (сейчас – вышла), Sun Microsystems, IONA . Цель OMG - достижение «быстрого роста технологии объектов» через развитие архитектуры управления объектами OMА (Object Management Architecture). OMА является концептуальным базисом, на котором основаны спецификации OMG. OMG «продвигает» еще такие известные стандарты как UML язык проектирования ПО, MDA (Model Driven Arch) поддержки всего жизненного цикла – от проектирования до реализации, развертывания и тестирования. CORBA развивается как система открытых стандартов с 1989г. Первый итоговый доку-мент OMG был опубликован в 1991г. В 1992г. вышел его переработанный вариант, а в 1994г. появилась версия CORBA 2.0. В настоящее время используется CORBA 2.3-5. Уже существует версия спецификации 3.0. На основе CORBA развивается компонентная модель объектов CCM (CORBA Component Model). Целью этого проекта является стандаризация процессов разработки распределенных систем на основе компонентной модели (контейнеры объектов, серверы приложений, автоматическая склейка компонент «внутри» сервера приложений и т.п.). CCM развивается в тесной связи с моделью EJB (Enterprise Java Beans) предлагаемой Sun Microsystems для разработки распределенных приложений. Активно развивается до сих пор.
 Поддерживаемые языки программирования: С, С++ (1998 - Java (1997 - ) Smalltalk (1994 - ) ADA (первая версия 1995) подчеркивает важность CORBA для специалистов разработки «технического» высокопроизводительного ПО COBOL (1999 – Lisp (1999 – ) CLORB a Common Lisp implementation of CORBA 2.6 Python (1999 – XML, для типов данных. “Авторы” CORBA Несмотря на то, что, формально, спецификации CORBA являются результатом работы некоммерческого консорциума OMG (Object Management Group), есть лица персонально «повязанные» с этой технологией. Douglas Schmidt Автор многих базовых шаблонов (patterns) распределенного программирования. Возглавляет коллектив центра Center for Distributed Object Computing (DOC), где уже более 10 лет разрабатывается один из основных комплектов разработки CORBA (ACE TAO). 24 миллиона 1995-2006 команда ~10 человек (Boeing, Lockheed Martin, McDonnell Douglas, DARPA). Системы реального времени в авионике, тренажерах, системы контроля за производственными процессами. Steve Vinoski, IONA (крупный разработчик ППО, Orbix, ORBacus) Michi Henning (родился в Германии) is Chief Scientist of ZeroC. From 1995 to 2002, he worked on CORBA as a member of the Object Management Group's Architecture Board, and as an ORB implementer, consultant, and trainer. He is the co-author of Advanced CORBA Programming with C++ and Distributed Programming with Ice.
В основе спецификации CORBA лежит язык IDL (Interface Definition Language), предназначенный для описания типов данных и типов объектов (интерфейсов). Описания IDL – не зависят от языка программирования, на котором будет реализована РС. Общее требование состоит в том, что для использования «удаленного объекта» вам должно быть достаточно предоставленного IDL-описания типов, используемых этим объектом. Как это реализовано технически будет рассказано позднее, а пока остановимся на ключевых понятиях языка. Рассмотрим для примера IDL описание калькулятора /* File DemoCalc.idl */ #pragma prefix "fivt.ru" module dcs { module demo { interface SimpleCalc { double add (in double a, in double b); double sub (in double a, in double b); double mult (in double a, in double b); }; /* Комментарий Пример наследования типа */ interface Calc : SimpleCalc { exception DivisionByZero { string reason; }; double div (in double a, in double b) raises (DivisionByZero); }; // Определение перечисления (Еще одна форма комментария) enum NumberType {DT_LONG, DT_FLOAT}; union Number switch(NumberType) { case DT_LONG: long longN; case DT_FLOAT: float floatV; }; interface SuperCalc { Number add (in Number a, in Number b); Number sub (in Number a, in Number b); Number mult (in Number a, in Number b); // Пример использования имени интерфейса/модуля (::) для ссылки на уже имеющийся тип данных. Number div (in Number a, in Number b) raises (Calc::DivisionByZero); }; typedef sequence valuetype BoxedNumberVector sequence interface VectorCalc { exception CheckDimensions { string comment; }; Number ScalarProduct (in NumberVector x, in NumberVector y) raises (CheckDimensions); Number BoxScalarProduct (in BoxedNumberVector x, in BoxedNumberVector y) raises (CheckDimensions); }; }; }; //(Обратить внимание на то, что имя файла никак не связано с названиями модулей)
Фактически стандарт CORBA представляет собой набор спецификаций, описывающих IDL (Interface Definition Language) Протоколы GIOP (IIOP), включая правила и формат упаковки данных, пердаваемых по сети. Программная архитектура Правила отображения на языки программирования (!) Общие правила разработки (использование предкомпиляторов и структура готовых фрагментов исходного кода) Спецификации стандартных служб (позже) Программная архитектура многозначное понятие. Это и логическая структура программных модулей, находящихся в отношении «основано-на», «состоит-из» и т.п., и описание API (Application Programming Interface). Различают «абстрактную архитектуру» некоторой модели программирования, и «устройство» конкретной реализации. Элементы приводимой ниже архитектуры CORBA находятся между собой в отношениях, аналогичных тем, что используются при описании «семиуровневой модели» 
Существует большой выбор комплектов разработчика систем на базе CORBA от различных поставщиков и ориентированных на разные языки программирования. Но везде присутствуют следующие необходимые элементы:
Для иллюстрации использования CORBA API приведем примеры операторов серверного и клиентского кодов, созданных предкомпилятором для IDL описания DemoCalс. | ||||||||||||||||||||||||||||||
nt add( int a, int b) {