Рис Физический и логический обмен данными по сети 21 Рис Ахитектура процессов в распределенных системах

Вид материала

Содержание

Примеры файлов, созданных предкомпилятором “из” DemoCalc.idl (интерфейс Calc)
Прозрачность в распр. системах
Вид прозрачности
Решается: стандарт ссылок, стандарт описания интерфейсов (?DL), использование универсального формата заявок.
Решается: стандарт ссылок, служба регистрации (хранит ссылки по их «описаниям»).
Базовые (примитивные) типы
Составные (пользовательские) и шаблонные типы
Еще один пример.
Value Type
An essential property of value types is that their implementations are always local.

Подобный материал:

1 2 3 4 5 6 7

Примеры файлов, созданных предкомпилятором “из” DemoCalc.idl (интерфейс Calc):

Имя файла (все с расширением .java)	Назначение	В каком фрагменте кода
Имя файла (все с расширением .java)	Назначение	серв.	клиент.
Calc	Базовый класс для объектов типа "сумматор". package dcs.demo; // модули IDL public interface Calc extends CalcOperations, org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity	x	x
CalcOperations	Абстрактный класс (в Java - типа interface) содержащий отображение методов и атрибутов интерфейса на язык Java, но без реализации.	x	x
CalcPOA	Фрагмент кода, содержащий скелетон интерфейса. public abstract class SmartCalcPOA extends org.omg.PortableServer.Servant implements org.omg.CORBA.portable.InvokeHandler, dcs.demo.CalcOperations	x
_CalcStub	Фрагмент кода, содержащий представитель (стаб) интерфейса.		x
CalcHelper	Специальный вспомогательный класс, содержащий набор методов, необходимых клиентской стороне (обычно - для манипуляций с объектными ссылками)	x	x (в основном здесь)

Примеры «реализаций» клиентской и серверной частей приложения

// Клиентский код. File CalcClient.java

package dcs.demo;

import dcs.demo.CalcPackage.DivisionByZero;

public class CalcServer {

static org.omg.CORBA.Object corbaObject = null;

public static void main(String[] args) {

org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null);

// String reference = ….

org.omg.CORBA.Object corbaObject = orb.string_to_object(reference);

dcs.demo.Calc calc = CalcHelper.narrow(calcObject);

double res = calc.add(1.,2.);

try {

res = calc.div(10.,0.);

} catch(DivizionByZero ex) {

System.out.println(“Не дели на ноль”);

}

}

}

// Серверные код. File CalcImpl.java

package dcs.demo;

import dcs.demo.CalcPackage.DivisionByZero;

public class CalcImpl extends CalcPOA { CalcImpl – «сервант»

public CalcImpl () {// Конструктор серванта

super();

};

public double add(double a, double b) { return a+b; }

public double div(double a, double b) throws DivisionByZero {

if (b < 1.E-08) {

DivisionByZero ex = new DivisionByZero("Denominator is too small");

throw ex;

}

return a/b;

}

// …….

}

// Серверный код. File CalcServer.java

package dcs.demo;

import dcs.demo.CalcPOA;

public class CalcServer {

static org.omg.CORBA.ORB orb;

static NameComponent[] fullNameComponent;

static NamingContextExt root;

static org.omg.PortableServer.POA rootPOA = null;

static org.omg.CORBA.Object calcObject = null;

public static void main(String[] args) {

orb = org.omg.CORBA.ORB.init(args, null);

CalcImpl servant = null;

try {

rootPOA = org.omg.PortableServer.POAHelper.narrow(

orb.resolve_initial_references("RootPOA")

);

} catch (org.omg.CORBA.ORBPackage.InvalidName ex) {

Log.logout(ex); System.exit(1);

} catch (org.omg.CORBA.BAD_PARAM ex) {

Log.logout(ex); System.exit(1);

}

try { rootPOA.the_POAManager().activate(); }

catch(org.omg.PortableServer.POAManagerPackage.AdapterInactive ex) {

Log.logout(ex.getMessage()); System.exit(1);

}

/**

* Activate CORBA Object возможно – с присваиванием объектного ключа

*/

try {

servant = new CalcImpl();

rootPOA.activate_object(servant);

// activate_object_with_id(“MyCalcID”, servant);

} catch(org.omg.PortableServer.POAPackage.ServantAlreadyActive ex) {

Log.logout(ex.getMessage()); System.exit(1);

} catch(org.omg.PortableServer.POAPackage.WrongPolicy ex) {

Log.logout(ex.getMessage()); System.exit(1);

}

} catch(org.omg.PortableServer.POAPackage.ServantAlreadyActive ex) {

Log.logout(ex.getMessage()); System.exit(1);

} catch(org.omg.PortableServer.POAPackage.WrongPolicy ex) {

Log.logout(ex.getMessage()); System.exit(1);

}

// Публикация ссылки на объект register server with naming context

System.out.println(orb.object_to_string(servant._this_object());

try {

orb.run();

} catch (org.omg.CORBA.NO_IMPLEMENT ex) {

Log.logout(ex); System.exit(1);

}

// …….

}

Сравнение централизованных и децентрализованных РВС

Централизованные	Распределенные
Содержат неавтономные компоненты (система имеет полный контроль над этими процессами/компонентами)	Содержат автономные компоненты (можно выключить удаленный хост, или он сам сломается)
Однородная технология	Разнородные платформы (ОСы, языки)
Ресурсы разделяются между многими пользователями (возможно, но не обязательно)	Также не является определяющим признаком !
Имеют один «центр управления» и администрирования	Несколько центров администрирования

Прозрачность в распр. системах

Требования «прозрачности» в РВС (Эммерих).

Стрелочки здесь означают «влияет-на». Например, «Прозрачность миграции» зависит от прозрачности доступа и местонахождения, которые «влияют-на».

Все эти требования, фактически являются требованиями к соотв. ППО и его службам.

Вид прозрачности	Комментарий
Прозрачность доступа	Вызов объекта определенного типа не должен зависеть от: реального места жительства объекта; от ОС хоста; от языка программирования, использованного при реализации. Зависит ТОЛЬКО от типа (интерфейса) объекта Программная компонента, где «живет» объект, может быть перенесена на другой компьютер, без необходимости переделывать «клиентский участок» кода. Решается: стандарт ссылок, стандарт описания интерфейсов (?DL), использование универсального формата заявок.
Прозрачность местонахождения	Объект может быть перенесен «незаметно» для других компонент РВС (отказал хост обитания). Решается: стандарт ссылок, служба регистрации (хранит ссылки по их «описаниям»). Клиент обращается к службе за ссылкой, которая обновляется при каждом запуске объекта.
Прозрачность миграции	- «» -
Прозрачность репликации	Возможность создания новых «копий» реплик объекта, например для обслуживания возросшего потока заявок Решается: спец. средства для сохранения состояния и копирования объектов (Persistence service). Добавить в CalcExt операцию toMem(float x):void; // x -> mem increment(float x): float // mem =+ x getMem(): float // get mem value
Прозрачность одновременного выполнения	Иллюзия «одновременного» выполнения заявок от различных клиентов. Управления очередями заявок, Load Balancing Services. Нарисовать

«Прозрачность доступа» на примере проблемы Big- и Little-endian

Память компьютера имеет байтовую организацию, а каждый байт имеет свой номер - адрес. Одного байта чаще всего недостаточно для хранения какой-либо информации (например, тип short хранится в двух байтах, long – в четырех, double – в восьми). Следовательно надо иметь возможность сохранять информацию в нескольких соседних байтах. Чтобы расположить информацию в нескольких байтах, можно выбрать один из двух способов.

Номера байтов	0	1	2	3
число (2041302511) (выбрано просто о аналогии с последовательностью 89ABCDEF, но 8 – не подходит т.к. если 1й первый бит – единица, то число отрицательное	79	AB	CD	EF
Старший и младшие байты	MSB			LSB

адрес

…

N+1

N+2

N+3

…

адрес

…

N+1

N+2

N+3

…

хранимое

значение

LSB

MSB

LSB

Тип представления Little-Endian

Тип представления Big-Endian

Big/Little Endians

Упомянуть о мониторах сетевой активности (Network Protocol Analyzer) Ethereal, Wireshark, позволяющих увидеть

Системы, на основе Intel-процессоров с архитектурой x86 используют тип Little-Endian. Системы на основе процессоров Sun Sparc (и ОС Sun Solaris), Motorolla, различных RISC-процессоров; 64-разрядная архитектура IA-64 – используют правило Big-Endian.

Это же правило применяется при чтении/записи числовых данных с использованием абстракций DataInput/DataOutput (последовательных устройств ввода-вывода) виртуальной машиной Java.

Решение в протоколе GIOP: использовать специальный бит среди флагов заголовка сообщения 0 – Big-endian; 1 – Little-endian.The byte order for fragment messages must match the byte order of the initial message that the fragment

extends.

Подробнее об IDL.

Базовые (примитивные) типы

Целочисленные

short -2¹⁵ .. 2¹⁵ - 1

long -2³¹ .. 2³¹ - 1

long long -2⁶³ .. 2⁶³ - 1

unsigned short 0 .. 2¹⁶ - 1

unsigned long 0 .. 2³² - 1

unsigned long long 0 .. 2⁶⁴ - 1

Плавающие

OMG IDL floating-point types are float, double and long double. The float type represents IEEE single-precision floating point numbers; the double type represents IEEE double-precision floating point numbers. The long double data type represents an IEEE double-extended floating-point number, which has an exponent of at least 15 bits in length and a signed fraction of at least 64 bits. See IEEE Standard for Binary Floating-Point Arithmetic, ANSI/IEEE Standard 754-1985, for a detailed specification.

Символы

char 8 bit

wchar (длина заранее не фиксирована, но, в первую очередь ориентирована на Unicode 16 bit)

Биты

boolean TRUE/FALSE

Октеты

octet 8 bit (удобен для пересылки произвольного содержания, т.к. CORBA гарантирует, что в содержимое НЕ будет изменяться; так например удобно пересылать содержимое «двоичных» файлов (графика)).

Произвольный тип

any универсальный контейнер

interfrace DoAny {

any do(in Any)

}

Составные (пользовательские) и шаблонные типы

Структуры (struct), объединения (union), массивы переменной длины (sequence) и перечисления (enum)

typedef sequence<>

typedef string<10> myString;

typedef sequence binFile;

typedef sequence binFile1000;

Структуры

struct Foo {

long myLong;

octet myOctet;

sequence myFlatArray; (сказать о типе «массив фиксированной длины»)

};

Связанный список значений структур…

struct List {

Foo value;

sequence next;

};

Описания интерфейсов

interface A { ... }

i
C

B

C

B

E
nterface B: A { ... }

interface C: A { ... }

i
D
nterface D: B, C { ... }

i
D
nterface E: A, B { ... };

Переменная типа «интерфейс» может быть параметром

#include "DemoCalc.idl"

module dcs {

module demo {

interface Proxy2Calc {

double redirect(in Calc c, in string op, in double a, in double b);

/* in Object c – дало бы возможность передавать ссылку на любой CORBA-объект */

};

};

};

Семантика команды redirect состоит в том, чтобы перенаправить выполнение команды, указанной в виде строки (значение параметра op) объекту, указанному в первом параметре. «Интерфейс-в-списке параметров» - всегда означает передачу ссылки на объект !

Еще один пример.

#pragma prefix "fivt.ru"

module dcs {

module demo {

module file {

module io {

exception IOException {

string mes;

};

exception FileNotFound {

string mes;

};

typedef sequence SeqOct;

typedef sequence SeqStr;

struct File {

SeqOct content;

SeqStr path;

};

};

interface FileServer {

void put(in io::File f) raises (io::IOException);

io::SeqOct get(in io::SeqStr path) raises (io::IOException, io::FileNotFound);

void getInOut(in io::SeqStr path, out io::SeqOct content) raises (io::IOException, io::FileNotFound);

};

};

};

};

Value Type

Можно передать ссылку на удаленный объект, можно передать структуру.

А можно ли передать объект «по-значению». Для этого в CORBA предусмотрен специальный

The basic notion is relatively simple. A value type is, in some sense, half way

between a “regular” IDL interface type and a struct. The use of a value type is a signal from the designer that some additional properties (state) and implementation details be specified beyond that of an interface type. Specification of this information puts some additional constraints on the implementation choices beyond that of interface types.

This is reflected in both the semantics specified herein, and in the language mappings.

An essential property of value types is that their implementations are always local.

That is, the explicit use of value type in a concrete programming language is always

guaranteed to use a local implementation, and will not require a remote call. They have no identity (their value is their identity) and they are not “registered” with the ORB.

There are two kinds of value types, concrete (or stateful) value types, and abstract

(stateless) ones. As explained below the essential characteristics of both are the same.

The differences between them result from the differences in the way they are mapped

in the language mappings. In this specification the semantics of value types apply to

both kinds, unless specifically stated otherwise.

Concrete (stateful) values add to the expressive power of (IDL) structs by supporting:

• single derivation (from other value types)

• supports a single non-abstract interface

• arbitrary recursive value type definitions, with sharing semantics providing the

ability to define lists, trees, lattices and more generally arbitrary graphs using value

types.

• null value semantics

When an instance of such a type is passed as a parameter, the sending context marshals the state (data) and passes it to the receiving context. The receiving context instantiates a new instance using the information in the GIOP request and unmarshals the state. It is assumed that the receiving context has available to it an implementation that is consistent with the sender’s (i.e., only needs the state information), or that it can

somehow download a usable implementation. Provision is made in the on-the-wire

format to support the carrying of an optional call back object (CodeBase) to the

sending context, which enables such downloading when it is appropriate.

It should be noted that it is possible to define a concrete value type with an empty state

as a degenerate case.

valuetype MyValueType {

private long MyState;

private string MyName;

factory MyInit(in long l. in string n);

long getState();

string getName{}

}

interface OBVServer {

void putOBV(in MyValueType mv);

module demo {

module value {

valuetype boxedLong long;

valuetype boxedString string;

valuetype Node {

public long id;

public Node next;

};

interface ValueServer {

string receive_long (in boxedLong p1, in boxedLong p2);

string receive_string (in boxedString s1, in boxedString s2);

string receive_list (in Node node);

};

};

};

Лекция 10

Объектная ссылка, устройство POA, протокол GIOP

Чтобы объяснить принципы адресации объектов CORBA. Нужно рассмотреть более подробно как устроен объектный адаптер.

Важно, что в задачу POA входит обеспечить соответствие между зарегистрированными на нем объектами (которым присвоено ID ) и реально существующими серверными объектами (сервантами)

Нарисовать иерархию POA и общую очередь заявок

Содержание объектной ссылки – адрес хоста + + + …

Еще раз напомнить, что ORB API позволяет задавать осмысленные имена всем элементам этой цепочки

Policy[] policies = new Policy[3];

policies[0] =

root_poa.create_lifespan_policy(LifespanPolicyValue.PERSISTENT);//PERSISTENT);//

policies[1] =

root_poa.create_id_assignment_policy(IdAssignmentPolicyValue.USER_ID);//USER_ID);//

policies[2] =

root_poa.create_implicit_activation_policy( ImplicitActivationPolicyValue.NO_IMPLICIT_ACTIVATION );

POA poa = root_poa.create_POA( "CalcPOA", root_poa.the_POAManager(), policies );

poa.the_POAManager().activate();

byte[] oid = "calc:1".getBytes();

CalcImpl servant = new CalcImpl();

poa.activate_object_with_id(oid, servant);

Важно, что стандарт CORBA использует язык IDL для описания всех структур используемых ORB, протоколами GIOP The CORBA specification uses pseudo-IDL to define how an IOR encodes the information required to send a request to the correct target object:

module IOP { // PIDL

typedef unsigned long ProfileId;

const ProfileId TAG_INTERNET_IOP = 0;

const ProfileId TAG_MULTIPLE_COMPONENTS = 1;

struct TaggedProfile {

ProfileId tag;

sequence profile_data;

};

struct IOR {

string type_id;

sequence profiles;

};

typedef unsigned long ComponentId;

struct TaggedComponent {

ComponentId tag;

sequence component_data;

};

typedef sequence MultipleComponentProfile;

};

At first glance, this is intimidating, but things are not quite as bad as they look. The main

data type in this IDL is struct IOR, which defines the basic encoding of an IOR as a

string followed by a sequence of profiles. The type_id string provides the interface

type of the IOR in the repository ID format we discuss in Section 4.19. The

profiles field is a sequence of protocol-specific profiles, usually one for each protocol

supported by the target object. For example, an IOR for an object that can be reached

either via IIOP or via DCE-CIOP has two elements in the profiles sequence. Figure

13.7 shows the main structure of an IOR.

Blog

Рис Физический и логический обмен данными по сети 21 Рис Ахитектура процессов в распределенных системах

Содержание