
- •Глава 2 Связь
- •2.1. Уровни протоколов
- •2.1. Уровни протоколов 83
- •84 Глава 2. Связь
- •2.1. Уровни протоколов 85
- •2.1.1. Низкоуровневые протоколы
- •86 Глава 2. Связь
- •2.1. Уровни протоколов 87
- •2.1.2. Транспортные протоколы (метод_Метелап лр_1)
- •88 Глава 2. Связь
- •2.1. Уровни протоколов 89
- •92 Глава 2. Связь
- •2.1.3. Протоколы верхнего уровня
- •2.1. Уровни протоколов 91
- •92 Глава 2. Связь
- •2.2. Удаленный вызов процедур 93
- •2.2. Удаленный вызов процедур
- •94 Глава 2. Связь
- •2.2.1. Базовые операции rpc
- •2.2. Удаленный вызов процедур 95
- •96 Глава 2. Связь
- •2.2. Удаленный вызов процедур 97
- •98 Глава 2. Связь
- •2.2.2. Передача параметров
- •2.2. Удаленный вызов процедур 99
- •100 Глава 2. Связь
- •2.2. Удаленный вызов процедур 101
- •102 Глава 2. Связь
- •2.2. Удаленный вызов процедур 103
- •2 .2.3. Расширенные модели rpc
- •104 Глава 2. Связь
- •2.2. Удаленный вызов процедур 105
- •106 Глава 2. Связь
- •2.2.4. Пример — dce rpc
- •2.2. Удаленный вызов процедур 107
- •108 Глава 2. Связь
- •2.2. Удаленный вызов процедур 109
- •110 Глава 2. Связь
- •2.3. Обращение к удаленным объектам 111
- •2.3. Обращение к удаленным объектам
- •112 Глава 2. Связь
- •2.3.1. Распределенные объекты
- •2.3. Обращение к удаленным объектам 113
- •114 Глава 2. Связь
- •2.3.2. Привязка клиента к объекту
- •2.3. Обращение к удаленным объектам 115
- •116 Глава 2. Связь
- •2.3. Обращение к удаленным объектам 117
- •2.3.3. Статическое и динамическое удаленное обращение к методам
- •118 Глава 2. Связь
- •2.3.4. Передача параметров
- •2.3. Обращение к удаленным объектам 119
- •120 Глава 2. Связь
- •2.3.5. Пример 1 — удаленные объекты dce
- •2.3. Обращение к удаленным объектам 121
- •122 Глава 2. Связь
- •2.3.6. Пример 2 — Java rmi
- •2.3. Обращение к удаленным объектам 123
- •124 Глава 2. Связь
- •2.3. Обращение к удаленным объектам 125
- •126 Глава 2. Связь
- •2.4. Связь посредством сообщений
- •2.4.1. Сохранность и синхронность во взаимодействиях
- •2 .4. Связь посредством сообщений 127
- •128 Глава 2. Связь
- •2.4. Связь посредством сообщений 129
- •130 Глава 2. Связь
- •2.4. Связь посредством сообщений 131
- •2.4.2. Нерезидентная связь на основе сообщений
- •132 Глава 2. Связь
- •2.4. Связь посредством сообщений 133
- •134 Глава 2. Связь
- •2.4. Связь посредством сообщений 135
- •136 Глава 2. Связь
- •2.4.3. Сохранная связь на основе сообщений
- •2.4. Связь посредством сообщений 137
- •1 38 Глава 2. Связь
- •2.4. Связь посредством сообщений 139
- •140 Глава 2. Связь
130 Глава 2. Связь
В корне отличный подход применен в системах передачи сообщений, использующих как отправную точку нерезидентную асинхронную связь и в качестве дополнительной возможности содержащих средства синхронной связи. Однако во всех вариантах передачи сообщений взаимодействия также предполагаются прозрачными. Другими словами, задействуются только те средства связи, кото-
2.4. Связь посредством сообщений 131
р ые подходят для синхронных процессов. Ограничиваться исключительно этими средствами во многих случаях нереально, особенно если принять во внимание географическую масштабируемость.
Необходимость в службах сохранной связи стала очевидной, когда разработчикам программного обеспечения промежуточного уровня потребовалось интегрировать приложения в крупные и сильно разветвленные взаимосвязанные сети. Подобные сети часто разбросаны по различным подразделениям и административным зонам, части которых не всегда могут быть доступны немедленно. Например, доступ может быть ограничен по причине сбоев в сети или процессах. Для решения подобных проблем были разработаны частные решения на базе сохранной связи, но подобные решения, как легко понять, не вполне удовлетворяли требованиям переносимости и работоспособности в разных условиях.
Другим недостатком нерезидентной связи можно считать тот факт, что в случае возникновения ошибки необходимо немедленно замаскировать ее и запустить процедуру восстановления. Невозможность отложить восстановление в данном случае означает нарушение прозрачности по отказам. В случае же сохранной связи приложение разрабатывается в расчете на длительные задержки между посылкой сообщения и получением ответа на него. Соответственно, мы можем прибегнуть к несложным, хотя возможно и медленным способам маскировки ошибок и восстановления.
Должно быть понятно, что выбор исключительно между нерезидентным и сохранным типами связи во многих случаях неприемлем. Аналогично, только синхронный и асинхронный типы связи — это еще не все. В зависимости от задач распределенной системы ей могут потребоваться все возможные типы связи. Ранее мы говорили в основном о нерезидентной синхронной связи — RPC и RMI. Другие формы взаимодействия, как правило, представлены системами, работающими на основе передачи сообщений. Эти системы мы обсудим в следующих пунктах. Мы проясним разницу между нерезидентной и сохранной связью.
2.4.2. Нерезидентная связь на основе сообщений
Множество распределенных систем и приложений непосредственно построено на базе простой модели обмена сообщениями, предоставляемой транспортным уровнем. Чтобы лучше понять и оценить системы, ориентированные на сообщения, как части решений промежуточного уровня, обсудим сперва обмен сообщениями через сокеты транспортного уровня.
Сокеты Беркли
Для стандартизации интерфейса транспортного уровня предпринимались специальные усилия. Это делалось для того, чтобы позволить программистам использовать полный комплект протоколов обмена сообщениями как простой набор примитивов. Кроме того, стандартные интерфейсы упрощают перенос приложений на другие машины.
В качестве примера мы кратко рассмотрим интерфейс сокетов, введенный в версии UNIX, разработанной в университете Беркли (Berkeley UNIX). Другой