Недостатки сетей на мостах. Алгоритм покрывающего дерева.

· Слабая защита от широковещательного шторма.

· Невозможность поддержки петлеобразных конфигураций сети.

Пример сети с петлеобразной конфигурацией:

В простых сетях сравнительно легко гарантировать существование одного и только одного пути между двумя сегментами.

Но когда количество соединений возрастает и сеть становится сложной, то вероятность непреднамеренного образования петли оказывается высокой.

Зачастую для надежности в сетях ввозят избыточные связи.

Для того чтобы избежать их некоторые порты блокируются для того, чтобы привести связи в сети к логической древовидной топологии.

Блокировка осуществляется как вручную, так и в автоматическом режиме.

Для автоматического блокирования используются специальные алгоритмы.

Альтернативные связи в сетях обычно используются двумя способами:

· в режиме резервирования, когда одно из них функционирует, а остальные находятся в «горячем» резерве для замены отказавшей связи

· в режиме баланса нагрузки; при этом данные передаются параллельно по всем альтернативным

Алгоритм покрывающего дерева - Spanning Tree Algorithm (STA) позволяет коммутаторам автоматически определять древовидную конфигурацию связей в сети при произвольном соединения портов между собой. Для нормальной работы коммутатора требуется отсутствие замкнутых маршрутов в сети.

Поддерживающие алгоритм STA коммутаторы автоматически создают активную древовидную конфигурацию связей (то есть связную конфигурацию без петель) на множестве всех связей сети. Такая конфигурация называется покрывающим деревом - Spanning Tree (иногда ее называют основным деревом), и ее название дало имя всему алгоритму. Алгоритм Spanning Tree описан в стандарте IEEE 802.1D.

Коммутаторы находят покрывающее дерево адаптивно, с помощью обмена служебными пакетами. При поддержке коммутаторами сети протокола Spanning Tree отказы обнаруживаются автоматически, за счет постоянного тестирования связности сети служебными пакетами. После обнаружения потери связности протокол строит новое покрывающее дерево, если это возможно, и сеть автоматически восстанавливает работоспособность.

Алгоритм Spanning Tree определяет активную конфигурацию сети за три этапа.

· Сначала в сети определяется корневой коммутатор (root switch), от которого строится дерево. Корневой коммутатор может быть выбран автоматически или назначен администратором. При автоматическом выборе корневым становится коммутатор с меньшим значением МАС - адреса его блока управления.

· Затем, на втором этапе, для каждого коммутатора определяется корневой порт (root port) - это порт, который имеет по сети кратчайшее расстояние до корневого коммутатора (точнее, до любого из портов корневого коммутатора).

· И наконец, на третьем этапе для каждого сегмента сети выбирается так называемый назначенный порт (designated port) - это порт, который имеет кратчайшее расстояние от данного сегмента до корневого коммутатора. После определения корневых и назначенных портов каждый коммутатор блокирует остальные порты, которые не попали в эти два класса портов. Можно математически доказать, что при таком выборе активных портов в сети исключаются петли и оставшиеся связи образуют покрывающее дерево (если оно может быть построено при существующих связях в сети).

Протокол HTTP

Hypertext Transfer Protocol (HTTP, протокол пересылки гипертекста) - это язык, которым клиенты и серверы World Wide Web пользуются для общения между собой. Кроме того, иногда HTTP фильтрует информацию и передает ее обратно пользователям - это происходит, например, когда в окне браузера отображаются коды ошибок сервера.

Все HTTP-транзакции имеют один общий формат. Каждый запрос клиента и ответ сервера состоит из трех частей: строки запроса (ответа), раздела заголовка и тела. Клиент инициирует транзакцию следующим образом:

1) Клиент устанавливает связь с сервером по назначенному номеру порта (по умолчанию - 80). Затем клиент посылает запрос документа, указав HTTP-команду, называемую методом, адрес документа и номер версии HTTP.

GET /index.html HTTP/1.0

2) Клиент посылает информацию заголовка (необязательную), чтобы сообщить серверу информацию о своей конфигурации и данные о форматах документов, которые он может принимать.

User-Agent: Mozilla/4.05 (WinNT; 1)

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

3) Послав запрос и заголовки, клиент может отправить и дополнительные данные. Эти данные используются главным образом теми CGI-программами, которые применяют метод POST.

Сервер отвечает на запрос клиента следующим образом:

1) Первая часть ответа сервера - строка состояния, содержащая три поля: версию HTTP, код состояния и описание.

HTTP/1.0 200 OK

2) После строки состояния сервер передает клиенту информацию заго­ловка, содержащую данные о самом сервере и затребованном документе.

Date: Fri, 10 Jan 2004 07:34:28 GMT

Server: Apache/2.2.6

Last-modified: Mon, 12 Jun 2003 22:54:48 GMT

Content-type: text/html

Content-length: 2482

3) Если запрос клиента успешен, то посылаются затребованные данные. Это может быть копия файла или результат выполнения CGI-программы. Если запрос клиента удовлетворить нельзя, передаются дополнительные данные в виде понятного для пользователя разъяснения причин, по которым сервер не смог выполнить данный запрос.

В HTTP 1.0 за передачей сервером затребованных данных следует разъединение с клиентом, и транзакция считается завершенной, если не передан заголовок Connection: Keep Alive.

Метод - это HTTP-команда, с которой начинается первая строка запроса клиента. Метод сообщает серверу о цели запроса. Для HTTP определены три основных метода: GET, HEAD и POST.

Метод POST позволяет посылать на сервер данные в запросе клиента. Эти данные направляются в программу обработки данных, к которой сервер имеет доступ. В качестве схемы кодирования с методом POST используется Ваsе64-кодирование.

Ответ сервера на запрос клиента состоит из трех частей. Первая строка -это строка ответа сервера, которая содержит номер версии HTTP, число, обозначающее состояние запроса, и краткое описание состояния. После строки ответа следует информация заголовка и тело содержимого, если таковое имеется.

Протокол SMTP

Основная задача протокола SMTP (Simple Mail Transfer Protocol) заключается в том, чтобы обеспечивать передачу электронных сообщений (почту). Для работы через протокол SMTP клиент создаёт TCP соединение с сервером через порт 25. Затем клиент и SMTP сервер обмениваются информацией пока соединение не будет закрыто или прервано. Основной процедурой в SMTP является передача почты (Mail Procedure). Далее идут процедуры форвардинга почты (Mail Forwarding), проверка имён почтового ящика и вывод списков почтовых групп. Самой первой процедурой является открытие канала передачи, а последней - его закрытие.

Команды SMTP указывают серверу, какую операцию хочет произвести клиент. Команды состоят из ключевых слов, за которыми следует один или более параметров. Ключевое слово состоит из 4-х символов и разделено от аргумента одним или несколькими пробелами. Каждая командная строка заканчивается символами перевода строки (CRLF). Вот синтаксис всех команд прото­кола SMTP (SP - пробел):

HELO <SP> <domain> <CRLF>

MAIL <SP> FROM:<reverse-path> <CRLF>

RCPT <SP> TO:<forward-path> <CRLF>

DATA <CRLF>

RSET <CRLF>

SEND <SP> FROM:<reverse-path> <CRLF>

SOML <SP> FROM:<reverse-path> <CRLF>

SAML <SP> FROM:<reverse-path> <CRLF>

VRFY <SP> <string> <CRLF>

EXPN <SP> <string> <CRLF>

HELP <SP> <string> <CRLF>

NOOP <CRLF>

QUIT <CRLF>

Обычный ответ SMTP сервера состоит из номера ответа, за которым через пробел следует дополнительный текст. Номер ответа служит индикатором состояния сервера.

Первым делом подключаемся к SMTP серверу через порт 25. Теперь надо передать серверу команду HELLO и наш IP адрес (здесь и далее символически обозначены: С: - запрос клиента, S: - ответ сервера): С: HELLO 195.161.101.33 S: 250 smtp.mail.ru is ready

При отправке почты передаём некоторые нужные данные (отправитель, получатель и само письмо):

С: MAIL FROM: <отправитель>

S: 250 OK

С: RCPT ТО: <получатель>

S: 250 ОК

указываем серверу, что будем передавать содержание письма (заголовок и тело письма)

С: DATA

S: 354 Start mail input; end with <CRLF>.<CRLF>

<само письмо>

передачу письма необходимо завершить символами CRLF.CRLF

S: 250 ОК

Теперь завершаем работу, отправляем команду QUIT: S: QUIT С: 221 smtp.mail.ru is closing transmission channel

С: From: Drozd <vasya@tut.by>

C: To: Drol <petya@mail.ra >

C: Subject: Hello

C: Hello vasya!

C: How are you?

<CRLF.CRLF>

S: 250 OK

S: QUIT

C: 221 smtp.mail.ru is closing transmission channel

Протокол РОРЗ

POP3 - это простейший протокол для работы пользователя с содержимым своего почтового ящика. Он позволяет только забрать почту из почтового ящика сервера на рабочую станцию клиента и удалить ее из почтового ящика на сервере. Всю дальнейшую обработку почтовое сообщение проходит на компьютере клиента.

РОРЗ - сервис, как правило, устанавливается на 110-й TCP-порт сервера, который будет находиться в режиме ожидания входящего соединения. Когда клиент хочет воспользоваться РОРЗ -сервисом, он просто устанавливает ТСР-соединение с портом ПО этого хоста. После установления соединения сервис РОРЗ отправляет подсоединившемуся клиенту приветственное сообщение. После этого клиент и сервер начинают обмен командами и данными. По окончании обмена РОРЗ -канал закрывается.

Ответы РОРЗ-сервера на команды состоят из строки статус-индикатора, ключевого слова, строки дополнительной информации и символов завершения строки - <CRLF>. Длина строки ответа может достигать 512 символов. Строка статус-индикатора принимает два значения: положительное ("+ОК") и отрица­тельное ("-ERR"). Любой сервер РОРЗ обязан отправлять строки статус-индикатора в верхнем регистре, тогда как другие команды и данные могут приниматься или отправляться как в нижнем, так и в верхнем регистрах.

РОРЗ-сессия состоит из нескольких частей. Как только открывается ТСР-соединение и РОРЗ-сервер отправляет приветствие, сессия должна быть зарегистрирована - состояние аутентификации (AUTHORIZATION state). Клиент должен зарегистрироваться в РОРЗ-сервере, т. е. ввести свой идентификатор и пароль. Это может быть выполнено либо с помощью команд USER и PASS - ввод открытых пользовательского идентификатора и пароля, либо командой АРОР - авторизации цифровой подписью, на базе секретного ключа.

После этого сервер предоставляет клиенту его почтовый ящик и открывает для данного клиента транзакцию - состояние начала транзакции обмена (TRANSACTION state). На этой стадии клиент может считать и удалить почту своего почтового ящика. Команда STAT (без аргументов) используется для просмотра состояния текущего почтового ящика.

В ответ РОРЗ- сервер возвращает строку, содержащую количество и об­щий размер в байтах сообщений, которые клиент может получить с РОРЗ- сер­вера. Сообщения, помеченные на удаление, не учитываются. Формат ответа: "+ОК nn mm", где пп - количество сообщений, mm - их общий объем:

С: STAT

S:+OK2 320

Команда RETR - используется для передачи клиенту запрашиваемого со­общения:

RETR msg

После получения, сообщение, как правило, помечается на удаление из почтово­го ящика, при этом используется команда DELE:

DELE msg

После того как клиент заканчивает работу (передает команду QUIT), сессия переходит в состояние UPDATE - завершение транзакции. В этом состоянии РОРЗ-сервер закрывает транзакцию данного клиента (на языке баз данных -операция COMMIT) и закрывает ТСР-соединение. Аргумент команды: номер сообщения. Сообщения, помеченные на уда­ление, реально удаляются только после закрытия транзакции, на стадии UPDATE.

Для проверки состояния соединения с РОРЗ- сервером используется команда NOOP. При активном соединении ответом на нее будет положительный инди­катор "+ОК":

Протокол FTP

FTP (RFC-959) обеспечивает файловый обмен между удаленными пользователями.

Работа FTP на пользовательском уровне содержит несколько этапов:

1. Идентификация (ввод имени-идентификатора и пароля).

2. Выбор каталога.

3. Определение режима обмена (поблочный, поточный, ascii или двоичный).

4. Выполнение команд обмена (get, mget, dir, mdel, mput или put).

Завершение процедуры (quit или close).

Команды и отклики передаются по управляющему соединению между клиентом и сервером в формате NVT ASCII. Клиент может отправить серверу более чем 30 различных FTP команд.

Отклики состоят из 3-циферных значений в формате ASCII, и необязательных сообщений, которые следуют за числами.

• 125 Соединение данных уже открыто; начало передачи.

• 200 Команда исполнена.

• 214 Сообщение о помощи (для пользователя).

• 331 Имя пользователя принято, требуется пароль.

• 425 Невозможно открыть соединение данных.

• 452 Ошибка записи файла.

• 500 Синтаксическая ошибка (неизвестная команда).

• 501 Синтаксическая ошибка (неверные аргументы).

• 502 Нереализованный тип MODE.

Управление соединением

Использовать соединение данных можно тремя способами.

1. Отправка файлов от клиента к серверу.

2. Отправка файлов от сервера к клиенту.

3.Отправка списка файлов или директорий от сервера к клиенту

Протокол Echo

Эхо-сервис весьма полезен для отладки и выполнения измерений. Этот сервис просто возвращает отправителю любые данные, полученные от него. Полное описание протокола можно найти в стандарте RFC 862.

Службы Echo на базе протокола TCP.

Один из вариантов эхо-сервиса определен как основанный на организа­ции соединений приложение TCP. Эхо-сервер прослушивает соединения TCP на порту 7. После организации соединения все полученные через это соедине­ние данные возвращаются отправителю. Процесс возврата полученных данных отправителю продолжается до тех пор, пока инициатор соединения не разорвет это соединение.

Службы Echo на базе протокола UDP.

Другой вариант эхо-сервиса не использует прямых соединений и основан на передаче дейтаграмм UDP. Эхо-сервер прослушивает порт 7 (UDP) и возвращает отправителю все принятые через этот порт дейтаграммы.

Time

Данный протокол предназначен для синхронизации времени. В сети работают time-серверы, у которых можно запросить точное время. Следует заметить, что в настоящее время для синхронизации времени в глобальных сетях используется более сложный протокол - NTP - Network Time Protocol. В ответ на запрос клиента, сервер возвращает время в секундах (32х битное двоичное число), прошедшее с 00:00:00 1 января 1900 года.

Этот протокол может использовать в качестве транспортной службы как UDP-протокол, так и TCP-протокол. Стандартный порт протокола - 37.

Если в качестве транспортной службы используется TCP, взаимодействие осуществляется так:

SERVER: прослушивает 37 порт, ожидая соединений CLIENT: запрашивает соединение с портом 37 сервера SERVER: посылает время в виде двоичного 32х битного числа CLIENT: получает время SERVER: закрывает соединение CLIENT: закрывает соединение

Если сервер по каким-либо причинам не может определить время на сво­ей стороне, он отказывается от соединения, не посылая ничего.

Если в качестве транспортной службы используется UDP, взаимодействие осуществляется так:

SERVER: прослушивает 37 порт, ожидая соединений CLIENT: посылает серверу пустой UDP-пакет, номер порта = 37 SERVER: получает пустой UDP-пакет

SERVER: посылает UDP-пакет, содержащий время в виде двоичного 32х битного числа

CLIENT: получает UDP-пакет, содержащий время

Если сервер по каким-либо причинам не может определить время на своей стороне, он отбрасывает полученный пустой UDP-пакет и не посылает ничего в ответ.

DayTime

Протокол DayTime определен в документе RFC867. Протокол может ис­пользовать в качестве транспортного протокола UDP и TCP. В случае использования UDP сервер занимает 13-й порт и ожидает поступления датаграмм. После получения датаграммы он отправляет по обратному адресу пакет, содержащий текущие дату и время в виде текстовой строки. Дополнительно, сервер выводит информацию о поступившем запросе на стандартный вывод. В случае использования TCP, как и в UDP, сервер занимает порт 13 и ожидает поступления запросов на установление соединения. После установления соединения, сервер отправляет клиенту строку, содержащую дату и время, и закрывает соединение.

Whols

Протокол Whois это информационный сервис. Несмотря на то, что любой узел может предоставить Whois сервис, наиболее широко используется InterNIC, rs.internic.net. Этот сервер содержит информацию обо всех зарегистрированных DNS доменах и о большинстве системных администраторов, которые ответственны за системы, подключенные к Internet. (Еще один подобный сервер nic.ddn.mil содержит информацию о сети MILNET.) К сожалению, не всегда предоставляется полная информация. RFC 954 [Harrenstein, Stahl, and Feinler 1985] документирует сервис Whois.

С точки зрения протокола, сервер Whois работает с заранее известным портом TCP 43. Он принимает от клиента запрос на соединение, после чего клиент отправляет на сервер запрос длиной в 1 строку. Сервер выдает информацию и закрывает соединение. Запросы и отклики передаются в формате NVT ASCII. Он практически идентичен серверу Finger, за исключением того, что запросы и отклики содержат разную информацию.

Широко используемый Unix клиент - программа whois, однако можно использовать Telnet и ввести команды самостоятельно. Сначала отправляется запрос, содержащий знак вопроса, на что возвращается более подробная ин­формация о поддерживаемых запросах клиента.

Finger

Протокол Finger возвращает информацию об одном или нескольких пользователях на указанном хосте. Это приложение обычно используется, для того чтобы посмотреть, находится ли конкретный пользователь в настоящее время в системе, или чтобы получить имя какого-либо пользователя, чтобы послать ему почту. RFC 1288 [Zimmerman 1991] описывает этот протокол.

Многие узлы не запускают Finger сервер по двум причинам. Во-первых, ошибки в программировании в ранних версиях сервера были одной из точек входа "червяка" в Internet в 1988 году. Во-вторых, протокол Finger может предоставить подробную информацию о пользователях (имя входа в систему, телефонные номера, время последнего входа и так далее), а эту информацию большинство администраторов считают частной. Раздел 3 RFC 1288 детально описывает аспекты секретности, соответствующие сервису Finger.

Сервер Finger использует заранее известный порт 79. Клиент осуществляет активное открытие на этот порт и отправляет запрос длиной в 1 строку. Сервер обрабатывает запрос, посылает назад вывод и закрывает соединение. Запрос и отклик в формате NVT ASCII, почти так же как мы видели в случае FTP и SMTP.

Обычно большинство пользователей Unix получают доступ к серверу Finger с использованием клиента finger, однако можно воспользоваться Telnet клиентом. Если запрос клиента состоит из пустой строки (которая в NVT ASCII передается как CR, за которой следует LF), это воспринимается как запрос на информацию о всех текущих пользователях.

RLogin

Rlogin появился в 4.2BSD и был предназначен для захода удаленным терминалом между Unix хостами. Поэтому Rlogin проще, чем Telnet, так как он не требует определения параметров, которые для одной и той же операционной системы известны заранее и для клиента, и для сервера. Через несколько лет Rlogin был перенесен на не-Unix системы.

RFC 1282 [Kantor 1991] содержит спецификацию протокола Rlogin. Однако, как и в случае с RFC посвященным RIP (Routing Information Protocol), он был написан после того, как Rlogin уже использовался в течении нескольких лет.Rlogin использует одно TCP соединение между клиентом и сервером. После того как TCP соединение установлено, между клиентом и сервером осуществляется следующая последовательность действий.

Клиент отправляет серверу четыре строки: нулевой байт, имя пользователя на хосте клиента, заканчивающееся нулевым байтом, имя пользователя на хосте сервера, заканчивающееся нулевым байтом, тип терминала пользователя, за которым следует слэш, затем следует скорость терминала, и все это заканчивается нулевым байтом. Необходимо отправить именно два имени пользователя, потому что пользователи не обязаны иметь одинаковые имена на разных хостах.

Тип терминала передается от клиента к серверу, потому что эта информация необходима для большинства полноэкранных приложений. Скорость терминала передается, потому что некоторые приложения работают по-разному в зависимости от скорости.

Сервер отвечает нулевым байтом.

У сервера есть опция, с помощью которой он просит ввести пароль. Это осуществляется как обычный обмен данными по Rlogin соединению - специальные протоколы не применяются. Сервер отправляет клиенту строку (которую клиент отображает на терминале), чаще всего эта строка выглядит как «Password:». Если клиент не вводит пароль в течение определенного времени (обычно 60 секунд), сервер закрывает соединение. Все что вводится в ответ на приглашение сервера ввести пароль, передается в виде открытого текста. Символы введенного пароля посылаются так, как они есть. Каждый, кто может прочитать пакеты в сети, может прочитать любой пароль.

Сервер обычно отправляет запрос клиенту, спрашивая размер окна терминала.

Клиент посылает за один раз серверу 1 байт, каждый байт сервер отражает эхо-откликом. Функционально все довольно просто: то, что вводит пользовтель, отправляется на сервер, а то, что сервер отправляет клиенту, отображается на терминале.

Telnet

Telnet был разработан, для того чтобы работать между хостами работающими под управлениием любых операционных систем, а также с любыми терминалами. Его спецификация, приведенная в RFC 854 [Postel and Reynolds 1983a], определяет терминал, который может являться наиболее общим, и который называется виртуальным сетевым терминалом (NVT - network virtual terminal). NVT это воображаемое устройство, находящееся на обоих концах соединения, у клиента и сервера, с помощью которого устанавливается соответствие между их реальными терминалами. Таким образом, операционная система клиента должна определять соответствие между тем типом терминала, за которым работает пользователь, с NVT. В свою очередь, сервер должен устанавливать соответствие между NVT и теми типами терминалов, которые он (сервер) поддерживает.

NVT это символьное устройство с клавиатурой и принтером. Данные, введенные пользователем с клавиатуры, отправляются серверу, а данные, полученные от сервера, поступают на принтер. По умолчанию клиент отражает эхом на принтер все, что ввел пользователь, однако, ниже мы увидим что, существуют опции, которые позволяют изменить подобное поведение.

Основные понятия CORBA.

Технология CORBA (архитектура брокера объектных запросов) была разработана концерном OMG (Object Management Group) для стандартизации технологии создания распределенных систем. Под распределенными системами здесь понимают программные комплексы, составные части которых функционируют на разных компьютерах в сети. Части комплексов взаимодействуют используя технологии самого различного уровня – от сокетов TCP/IP до технологий с высоким уровнем абстракции. Примнительно к CORBA универсальным считается решение, которое не зависит от языка программирования, аппаратной платформы, ОС, сетевого протокола передачи данных, двоичных стандартов и структур. На основании этого OMG декларировало технологию CORBA как универсальную технологию создания распределенных систем в интероперабельных средах.

Основные понятия:

CORBA-объект – виртуальное понятие: он представляет собой нечто, расположенное на брокере объектных запросов, посылающее запросы к другим CORBA-объектам – серверным объектам и получающее запросы от других CORBA-объектов – клиентов. Идентификатор объекта (object ID) – уникальное имя объекта внутри его объектного адаптера. Он представляет собой последовательность байт, которая ассоциируется с объектом в момент его создания. Сервант – серверная программа, написанная на каком-либо из языков программирования и выполняющая CORBA-объект. Скелетон– серверная программа, которая связывает сервант с объектным адаптером, позволяя объектному адаптеру перенаправлять запросы к соответствующему серванту. Активизация – запуск существующего CORBA-объекта для обработки клиентских запросов. Активизация предполагает, что интересующий клиента объект имеет подходящий сервант. Активизированные объекты бывают двух типов: устойчивые и временные. Деактивизация – действие, обратное активизации, останов CORBA-объекта, разрыв связки между объектом и сервантом, в общем случае без разрушения объекта. Инкарнация – это связывание серванта с CORBA-объектом для обработки клиентского запроса. Эфемеризация – в противоположность инкарнации разрушение связки CORBA-объект – сервант со стороны серванта. Карта активных объектов (Active Object Map)– таблица объектного адаптера, в которой он ведет реестр активных CORBA-объектов и связанных с ними сервантов.

Сервисы CORBA

1.Naming Service – сервис именования. Он представляет собой возможность связывания имен с объектами относительно именного контекста. Именной контекст является объектом содержащим множество уникальных именованных связей. Доступ к объекту производится механизмом разрешения имен. Это определение объекта по ассоциированному с ним имени в данном именном контексте.

2.Event Service – сервис событий. Он позволяет универсальным образом уведомлять объекты распределенной системы о происходящих событиях. Служит для организации Call Back вызовов (механизма обратного вызова). В настоящее время сервис является базовым для более развитого и обобщенного сервиса уведомлений.

3.Persistent Service – сервис долговременного хранения. Обеспечивает универсальный механизм сохранения состояний CORBA- объектов как в реляционных так и в объектных базах данных.

4.Life Cycle Service – сервис жизненного цикла. Отвечает за операцию создания, копирования перемещения и удаления объектов. Является набором интерфейсов, многие методы которых необходимо реализовывать самостоятельно. Работает в тесной связи с сервисом отношений.

5.Relationship Service– сервис отношений. Позволяет динамически устанавливать связи между объектами. Совокупности отношений образуют графы и рассматриваются как CORBA- объекты. Используются при копировании, перемещении или удалении группы связанных друг с другом объектов.

6.Properly Service – сервис свойств. Позволяет сопоставлять с объектами те или иные свойства виде пары имя-значение.

7.Security Service-сервис безопасности. Решает многие стандартные проблемы безопасности: Идентификация пользователя; Определение прав доступа; Защита информации при передачи и т.д. Распространение контекста безопасности осуществляется ORB.

8.Trading Service – трейдер сервис. Сервис поиска с помощью которого клиент получает нужную объектную ссылку. Поиск осуществляется не по имени, а по совокупности свойств объекта.

9.Externalization Service – сервис внешнего представления. Предназначен для построения образа объекта, взаимодействующего со стандартными потоками ввода-вывода (эквивалентен механизму сериализации в Java)

10.Transaction Service – сервис транзакции. Взаимодействует на уровне реализации с ORB и служит для управления транзакциями. Поддерживает двухфазное подтверждение транзакции и вложенную транзакцию.

11.Concurrency Control Service – сервис совместного доступа. Предназначен для универсального управления разделяемыми ресурсами. Осуществляет координацию параллельных транзакций.

12.Query Service – сервис запросов. Предназначен для выполнения поиска объектов соответствующих определенным критериям. Языком выполнения является либо OQL либо расширенный SQL. Результатом является совокупность объектов для манипуляции которыми используется сервис контейнеров.

13.Collections Service – сервис контейнеров. Позволяет определять группы объектов и управлять ими единообразным способом. Использует стандартные контейнеры: множества, наборы, последовательности и др. Для каждого контейнера определяется своя фабрика (интерфейс для создания контейнеров) и итератор.

14.Licensing Service – сервис лицензирования. Служит для отслеживания использования CORBA- объекта и для ограничения его применения по разным критериям. 15.Time Service – сервис времени. Служит для синхронизации часов на различных компьютерах. Основой является UTC.

Технология RMI. Основные понятия технологии JavaBeans.

Технология RMI (удаленный вызов методов) была разработана для языка Java для обеспечения передачи сообщений от объекта существующего в контексте одной виртуальной машины Java к объекту существующему в контексте другой.

RMI оказала влияние на технологии взаимодействия, которые использует CORBA.

RMI использует 2 стандартных протакола обмена:

Собственный неуниверсальный протокол обмена (RMP)

Стандартный для CORBA протокол (IIOP)

Поддержка последнего протокола позволяет RMI приложениям получить доступ ко всем сервисам CORBA и возможность доступа к CORBA серверам написанным на любом языке.

В свою очередь интеграция с RMI позволяет CORBA компенсировать отсутствие в настоящий момент собственной компонентной модели и универсального мониторинга транзакций.

В основу RMI заложены средства сериализации Java. Последовательность создания приложения с использованием RMI следующая:

· определение удаленных интерфейсов путем наследования стандартного интерфейса java.rmi.remote

· создание класса реализующего данный интерфейс. Это достигается путем наследования класса java.rmi.UnicastRemoteObject

· генерация специального кода заглушки, как для клиента так и для сервера с помощью компилятора rmic.

· запуск службы имен на стороне сервера rmi registry

· создание серверного приложения, которое использует классы заглушки. Это приложение служит для создания серверных объектов и регистрации их в службе имен.

· создание клиентского приложения с реализованным в нем механизмом вызова удаленных методов с передачей им аргументов посредством сериализации объектов Java.

Библиотека rmi большей частью использует интерфейсы и поэтому с помощью них предусматривается наличие подсистем поиска объектов по именам, управления безовасности, маршалинга (Маршалинг – способ вызова удаленного объекта который находится на другой машине или другой Java-машине без пересоздания кода вызывающего удаленный метод).

При создании удаленного объекта передается ссылка не на сам объект а на интерфейс по которому создается серверная заглушка, которая и проводит пересылку по сети.

Технология, в которых нашли применение как RMI так и CORBA образовав множество называемое RMI/IDL является технологией фирмы Sun Enterprise Java Beans (EJB).

Основные понятия технологии JavaBeans.

Среда JavaBeans является надстройкой над стандартной Java-технологией. Она наследует понятия и характеристики Java, такие как объектная ориентированность, многопоточность, использование виртуальной машины, независимость от аппаратно-программной платформы, информационная безопасность и т.п. В JavaBeans нет ничего, не выразимого в терминах языка Java. Основой среды JavaBeans является компонентная объектная модель, представляющая собой совокупность архитектуры и прикладных программных интерфейсов. Архитектуру образуют основные понятия и связи между ними. Прикладные программные интерфейсы характеризуют набор сервисов, предоставляемых элементами среды. Они описываются в терминах синтаксиса и семантики Java-классов и интерфейсов.

К числу основных понятий архитектуры JavaBeans относятся компоненты и контейнеры. Контейнеры могут включать в себя множество компонентов, образуя общий контекст взаимодействия с другими компонентами и с окружением. Контейнеры могут выступать в роли компонентов других контейнеров.

Неформально компонент ("кофейное зерно" - Java Bean) можно определить как многократно используемый программный объект, допускающий обработку в графическом инструментальном окружении и сохранение в долговременной памяти. С реализационной точки зрения компонент - это Java-класс и, возможно, набор ассоциированных дополнительных классов. Каждый компонент предоставляет набор методов, доступных для вызова из других компонентов и/или контейнеров. Компоненты могут обладать свойствами. Совокупность значений свойств определяет состояние компонента. Свойства могут быть доступны на чтение и/или запись посредством методов выборки и установки. Компоненты могут порождать события (быть источниками событий), извещая о них другие компоненты, зарегистрировавшиеся в качестве подписчиков. Извещение (называемое также распространением события) заключается в вызове определенного метода объектов-подписчиков. Типичным примером события является изменение свойств компонента. В общем случае компонент может предоставлять подписку на получение информации об изменении и на право запрещать изменение. Методы, свойства и события образуют набор афишируемых характеристик компонента, то есть характеристик, доступных инструментальному окружению и другим компонентам. Этот набор может быть выяснен посредством механизма интроспекции. Состояние компонентов может быть сохранено в долговременной памяти. Наличие методов для подобного сохранения выделяет компоненты JavaBeans среди произвольных Java-классов.

Компоненты JavaBeans могут упаковываться для более эффективного хранения и передачи по сети. Описание соответствующего формата является частью спецификаций JavaBeans.

Жизненный цикл компонентов JavaBeans можно подразделить на три этапа:

· разработка и реализация компонента;

· сборка приложения из компонентов;

· выполнение приложения.

Разработка и реализация компонентов JavaBeans по сути не отличается от создания произвольных Java-объектов, хотя и может включать реализацию специфических методов. Сборка приложений выполняется, как правило, в инструментальном окружении, позволяющем проанализировать афишируемые характеристики компонентов, настроить значения свойств, зарегистрировать подписку на получение событий, организовав тем самым взаимодействие компонентов. Разработчик компонента может реализовать специальные методы для использования исключительно в инструментальном окружении (например, редактор свойств). Компоненты взаимодействуют между собой и с инструментальным окружением. Взаимодействие осуществляется двумя способами - вызывом методов и распространением событий. Спецификации JavaBeans описывают только локальное взаимодействие компонентов, осуществляемое в пределах одной виртуальной Java-машины. (Напомним, впрочем, что Java-апплеты рассчитаны на передачу по сети, так что возможно собрать приложение из компонентов, первоначально распределенных по сети.) Удаленные объекты могут связываться по протоколам архитектуры CORBA [7], с помощью удаленного вызова методов (Remote Method Invocation - RMI) или иными способами, не относящимися к области действия спецификации JavaBeans.

Основные понятия технологии Enterprise JavaBeans.

Enterprise JavaBeans (EJB) — спецификация технологии написания и поддержки серверных компонент, содержащих бизнес-логику. Является частью Java EE.

Сервер EJB – это среда времени выполнения, в которой могут функционировать компоненты. Его задача – обеспечить доступ к системным сервисам, необходимым для работы компонентов. Важнейшим из этих сервисов является сервис распределенных транзакций (JTS). Сервер EJB не взаимодействует непосредственно с компонентами – это задача так называемого Контейнера (Container) EJB. Контейнер EJB взаимодействует с сервером, когда одному или нескольким компонентам, находящимся под управлением Контейнера, необходим доступ к системным ресурсам. Контейнер представляет собой совокупность классов и программных средств, работающих в контексте Сервера EJB. Контейнер, в частности, обеспечивает:

- управление циклом жизни компонента – его созданием, инициализацией, сохранением его состояния в базе данных, если это необходимо;

- возможность поиска клиентом нужных ему объектов;

- гарантию того, что вызов методов происходит в контексте нужной транзакции;

- базовый уровень обеспечения безопасности;

- наличие инструментов разработчика, например, компилятора для генерации стабов.

Компонент EJB – это класс Java, который, собственно, и реализует всю необходимую функциональность. Необходимо четко понимать, что сам компонент в принципе недоступен для клиента. Клиент обращается к нему косвенно, через специальный интерфейсный объект-посредник (proxy). В литературе по EJB он обычно называется EJBObject. Время существования компонента и его proxy-объекта в общем случае различно. Сам компонент находится под управлением Контейнера, и пользователь в общем случае не может быть уверен, что два последовательных вызова клиента будут обслужены одним и тем же компонентом.

Транзакция, управляемая компонетом (Bean Managed Transaction, BMT): Управление транзакцией берет на себя компонент. Только Session-компоненты могут использовать такой режим. Только в этом режиме вызов одного из удаленных методов может привести к началу транзакции, но не обязательно к ее завершению – несколько последующих вызовов могут происходить в контекст этой же транзакции.

Транзакция, управляемая Контейнером (Container Managed Transaction, CMT): Режим разрешен как для Session-, так и для Entity-компонентов. Компонент не имеет возможности ни начать, ни завершить транзакцию (хотя любой из участников транзакции может потребовать ее отката (rollback) при завершении) – управление транзакцией полностью берет на себя Контейнер. Транзакция начинается при вызове каждого удаленного метода и завершается при возврате из него. Программист может установить один из нескольких разрешенных режимов, определяющих поведение транзакции.

Дескриптор развертывания (иногда используются термины «установки» или «поставки» - в настоящий момент еще нет устоявшегося термина на русском языке)- необходим для настройки созданного компонента на работу в конкретной операционной среде. Необходимость в нем возникает из-за того, что спецификация EJB четко определяет несколько этапов, который проходит компонент от своего создания до доставки конечному пользователю с окончательной настройкой.