Контрольные вопросы и задания




НазваниеКонтрольные вопросы и задания
страница4/9
Дата конвертации22.01.2013
Размер1.38 Mb.
ТипКонтрольные вопросы
1   2   3   4   5   6   7   8   9
– операции транзакции образуют неразделимый, атомарный блок («unit of work» – «единица работы») с определенным началом и концом. Этот блок либо выполняется от начала до конца, либо не выполняется вообще. Если в процессе выполнения транзакции произошел сбой, происходит откат к исходному состоянию;

Consistency (согласованность) – по завершении транзакции все задействованные ресурсы находятся в согласованном состоянии;

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

Durability (долговременность) – все модификации ресурсов в процессе выполнения транзакции будут долговременными.

В системе без TPM обеспечение свойств ACID берут на себя серверы распределенной базы данных на основе протокола 2РС – (two-Phase Commit – двухфазное подтверждение). Протокол 2РС описывает двухфазный процесс, в котором перед началом распределенной транзакции все системы опрашиваются о готовности выполнить необходимые действия. Если каждый из серверов баз данных дает утвердительный ответ, транзакция выполняется на всех задействованных источниках данных. Если хотя бы в одном месте происходит какой-либо сбой, будет выполнен откат всех частей транзакции.

Однако в системе с распределенными базами данных выполнение протокола 2РС можно гарантировать только в том случае, если все источники данных принадлежат одному поставщику. Поэтому для сложной распределенной среды, которая обслуживает тысячи клиентских мест и работает с десятками разнородных источников данных, требуется использование механизма монитора обработки транзакций. Транзакционные мониторы способны координировать и управлять транзакциями, которые обращаются к серверам баз данных от различных поставщиков благодаря тому, что большинство этих продуктов помимо протокола 2РС поддерживают транзакционную архитектуру общего стандарта распределенной обработки транзакций DTP (Distributed Transaction Processing) для данной категории MW. Архитектура DTP поддерживает совместное использование ресурсов (файлов или баз данных) множеством программ, обеспечивая управление доступом, гарантирующее согласованность системы в целом.

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

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

Архитектура транзакционных мониторов включает клиентский интерфейсный компонент и поддержку прямого доступа через терминал. Программный поток исполняет процедуры, написанные на языке данного монитора, которые содержат операции над именованными логическими ресурсами. Маршрутизатор сопоставляет операции и вызовы, которые могут относиться к ресурсам (например, базе данных) или локальным службам самого монитора. В состав маршрутизатора входит специализированная база данных, содержащая определения соответствий между именами логических ресурсов и физическими устройствами. При изменении системы администратор исправляет это соответствие: клиентское приложение модифицировать не требуется – клиент знает только логические имена. Взаимодействие с ресурсами осуществляется через менеджера взаимодействия (например, систему сообщений, обеспечивающую откат и гарантию доставки). Разнородность ресурсов, связанных с монитором, скрывают оболочки. Выполнение транзакции проводит менеджер транзакций, исполняющий протокол 2РС и гарантирующий транзакционные свойства процедур, исполняемых транзакционным монитором.

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

Полезность транзакционных мониторов и последующее появление брокеров объектов привело к построению объектно-ориентированных транзакционных мониторов или объектных мониторов транзакций ОТМ (object transaction monitor). Системы OTM берут лучшее из двух технологий. Они поддерживают объектную модель и при этом обеспечивают целостность распределенных транзакций на множестве разнородных источников данных, масштабируемость, надежность и высокую производительность – основные качества, присущие транзакционным мониторам. Кроме того, ORB сами по себе, как правило, не реализуют возможностей оптимального распределения нагрузки и восстановления при сбоях. Эти важнейшие службы высококритичной распределенной среды добавляются путем интеграции с технологией транзакционных мониторов. При этом ОТМ способны упростить развертывание транзакционных приложений. ТРM – одна из самых сложных в реализации категория MW, а строгая объектная архитектурная надстройка позволяет скрыть ее сложности от разработчика. Многие ОТМ также интегрируются с сервисами очередей сообщений (см. раздел 2.4), поддерживая тем самым асинхронную модель коммуникаций.

Системы ОТМ отличаются от других средств интеграции разных категорий MW тем, что все необходимые свойства ТРM и ORB предоставляются в одном продукте. Многие представители категории ОТМ базируются на компонентной модели CORBA/Java (эти две технологии построения распределенных компонентных сред все более тесно интегрируются друг с другом) и стандартной транзакционной архитектуре DTP, поддерживая при необходимости работу с объектами DCOM. Так, консорциумом OMG была разработана спецификация объектного сервера транзакций OTS (Object Transaction Server), цель которой – унифицировать объединенную функциональность мониторов транзакций и брокеров объектных запросов. Это расширение CORBA нашло свое отражение в спецификации JTS для Java (Java Transaction Service служба транзакций Java).



    1. Распределенная обработка информации

на основе технологий обмена сообщениями

Промежуточное ПО, ориентированное на обмен сообщениями (Message Oriented Middleware – MOM), относительно молодая и динамично развивающаяся категория систем промежуточного слоя. Согласно этой модели приложения обмениваются байтовыми строками – сообщениями, обращаясь к API-интерфейсу системы MOM, который изолирует их от непосредственного взаимодействия с ОС и сетевыми протоколами. В отличие от ранее рассмотренных моделей промежуточного ПО, MOM реализует скорее равноправные (peer-to-peer), чем подчиненные (клиент-сервер) отношения между модулями приложений. MOM можно считать и наиболее гибкой категорией MW, поскольку системы этого типа поддерживают как синхронные, так и асинхронные коммуникации на базе сетевых протоколов с установлением и без установления соединения. По способу обмена сообщениями все продукты MOM могут быть разделены на три подгруппы систем:

1) с передачей сообщений,

2) c очередями сообщений,

3) типа публикация/подписка.

Системы с передачей сообщений (Message Passing – MP) обеспечивают непосредственное взаимодействие приложений друг с другом путем отправки и получения сообщения. Для этого между программными модулями устанавливается логическое соединение. Отсюда следует, что данное решение не подходит для слабо связанных программ, работающих в независимом временном режиме, например, приложений, определенные компоненты которых обслуживают мобильных пользователей. Обмен сообщениями может происходить в синхронном и асинхронном режиме. Кроме средства непосредственных коммуникаций, системы этого типа могут обеспечивать дополнительные службы промежуточного слоя, например, службу каталогов.

Многочисленная часть МОМ-систем реализует асинхронный механизм очередей сообщений (Message Queuing – MQ). В отличие от передачи сообщений, эта модель межпрограммного взаимодействия не требует поддержки непосредственного соединения одного прикладного модуля с другим, но гарантирует доставку сообщения даже в том случае, если программа-адресат в данный момент не доступна. Программа-отправитель передает сообщение MQ-системе и продолжает выполнение. Сообщение помещается в локальное промежуточное хранилище – очередь сообщений, размещенную в оперативной памяти или на диске, откуда оно может быть немедленно или через какое-то время передано программе-получателю. Таким образом, приложения, которые используют эту модель связи, могут работать практически независимо друг от друга без временной синхронизации. Поэтому механизм очередей сообщений является удачным решением для приложений, предназначенных мобильным пользователям, для реализации потоков работ и поддержки приложений в глобальных сетях с медленными и не очень надежными соединениями.

Большинство MQ-систем включает менеджер очереди (Queue Manager), который управляет локальными очередями, гарантирует передачу сообщений нужному адресату и, взаимодействуя с менеджерами на других узлах, следит за сетевым маршрутом передачи сообщения, выбирая альтернативный путь, если по тем или иным причинам основной оказывается недоступен.

Принципиальная схема организации механизма очередей сообщений представлена на рис. 2.5.




Рис. 2.5. Принципиальная схема организации механизма

очередей сообщений

Очереди сообщений могут быть долговременными (persistent) или нет. В последнем случае, если произойдет сбой в работе менеджера очередей, то сообщения в очереди будут потеряны. Если поддерживается долговременная очередь, сообщения будут восстановлены после перезапуска менеджера. Этот вариант безусловно является предпочтительным для большинства ответственных приложений.

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

надежная доставка сообщений (reliable message delivery) – система гарантирует, что в процессе обмена сообщениями ни один сетевой пакет не будет потерян;

гарантированная доставка сообщений (guaranteed message delivery) – сообщение доставляется адресату немедленно или через заданный промежуток времени, не превышающий определенного значения (в случае, если сеть в данный момент не доступна);

застрахованная доставка сообщений (assured message delivery) – каждое сообщение доставляется только один раз.

Промежуточные системы на базе очередей сообщений могут поддерживать обработку транзакций, разбивая большие синхронные транзакции, которые модифицируют несколько распределенных, разнородных баз данных, на меньшие асинхронные транзакции, взаимодействующие друг с другом посредством очередей. Таким образом МОМ-системы могут использоваться как более производительный асинхронный коммуникационный уровень для мониторов обработки транзакций ТРM.

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

Представителями программных продуктов, построенных на базе очередей сообщений, являются системы MQSeries компании IBM, MSMQ (Microsoft Message Queuing Server) компании Microsoft, MessageQ компании BEA, dbQ компании Sybase.

Еще одна модель обмена сообщениями – модель публикации/подписки (publlsh&subscribe) – имеет определенные перспективы для создания гибких, управляемых событиями приложений. Одно приложение публикует информацию в сети, а другое подписывается для получения данных по интересующей его теме. Взаимодействующие таким способом приложения полностью независимы друг от друга и могут ничего не знать о существовании, физическом размещении и состоянии друг друга. Это открывает путь к динамической реконфигурации всей распределенной системы, добавлению и произвольному изменению любых клиентов и серверов без прерывания их работы и полной изоляции прикладных компонентов от любых аспектов реализации других частей системы. В конечном итоге, это означает возможность эффективной интеграции различных бизнес-приложений в единое корпоративное решение.

Характерным примером распределенной системы на основе модели публикации/подписки является система TIB/Rendezvous компании TIBCO. Ключевой механизм, лежащий в основе системы TIB/Rende­zvous, – это адресация по теме (subject-based addressing). При таком подходе процесс, который собирается посылать сообщение, не может определить точное место назначения. Вместо этого он именует сообщение названием темы (subject name), после чего посылает его в коммуникационную систему для пересылки по сети. Получатели, в свою очередь, не выясняют, от каких процессов они собирают­ся получать сообщения. Вместо этого они сообщают коммуникационной систе­ме, какие темы их интересуют. Коммуникационная система гарантирует, что по­лучателю будут доставлены только те сообщения, которые несут данные по теме, интересующей получателя.

Отправка сообщения методом адресации по теме также называется публика­цией (publishing). Чтобы получить сообщение по определенной теме, процесс дол­жен подписаться на эту тему. Принципиальная схема организации системы публикации/под­писки, реализованная в TIB/Rendezvous, показана на рис. 2.6.

Основой архитектуры системы TIB/Rendezvous являет­ся сеть с поддержкой групповой рассылки, хотя по возможности допускается ис­пользование более эффективных средств связи (так, например, если известно точное местонахождение подписчика, обычно выполняется сквозная передача со­общений). На каждом узле этой сети работает демон контактов (rendezvous dae­mon), который отвечает за то, чтобы сообщения отсылались и получались в соот­ветствии с темой. Когда сообщение публикуется, демон контактов осуществляет его групповую рассылку всем узлам сети. Обычно групповая рассылка реализуется средствами базовой сети, такими как групповая рассылка по IP-адресам или аппаратная широковещательная рассылка.

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




Рис. 2.6. Принципиальная схема организации системы

публикации/под­писки


Чтобы система могла вырасти до размера больших сетей, таких как глобальные сети, используются также маршрутизирующие демоны контактов (rendezvous router daemons). Обычно каждая локальная сеть имеет одного маршрутизирующего де­мона контактов. Этот демон связывается с маршрутизирующим демоном другой удаленной сети. Маршрутизирующие демоны образу­ют сквозную оверлейную сеть (overlay network), в которой маршрутизаторы со­единены между собой попарно соединениями TCP. Вторичная сеть – это сеть маршрутизаторов прикладного уровня. Каждый маршрутизатор знает топологию вторичной сети и вычисляет дерево групповой рассылки для публикации сообщений в других сетях. Маршрутизато­ры рассылают только те сообщения, которые публикуются в их локальной сети. Сообщения из других сетей пересылаются по дереву групповой рассылки той се­ти, из которой они первоначально исходили.

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

Технологической основой для всех сред обмена сообщениями нового поколения стала спецификация JMS (Java Message Service – служба сообщений Java), в деталях определяющая, как взаимодействуют клиенты и серверы в среде асинхронных сообщений. К числу достоинств JMS относится то, что она соответствует современным представлениям о взаимодействии приложений и не требует специальных знаний и доступна для любого программиста, работающего на языке Java. Этими качествами она заметно отличается от инструментария MQSeries, где необходима специальная подготовка. Еще один стимул для рождения нового поколения MOM – появление расширяемого языка разметки данных XML (eXtensible Markup Language – «расширяемый язык разметки») для Internet-приложений, позволяющего одним приложениям «понимать» другие.

Спецификация JMS построена на основе топологии «ступицы и колеса» (hub-and-spoke), в которой все приложения подключаются к центральному процессу, называемому сервером сообщений (message server). Он отвечает за корректность маршрутизации сообщений, аутентификацию и авторизацию пользователей. Сами приложения рассматриваются как клиенты – они могут быть передатчиками и/или приемниками. При этом обеспечивается такой API-интерфейс на базе Java, который позволяет разработчикам писать клиентские приложения, не заботясь о том, какое конкретно программное обеспечение MOM будет использоваться. Спецификация только определяет доступ к корпоративной системе обмена сообщениями, а каждый производитель ПО, опирающийся на JMS, самостоятельно разрабатывает инструменты для администрирования среды обмена сообщениями. JMS стала основой целого направления программных продуктов категории MOM, таких как MQ Express компании Talarian, SonicMQ компании Progress Software, Bus компании Softwired, FioranoMQ компании Fiorano Software и других.


2.5. Распределенная обработка информации

на основе моделей согласования


Основным подходом, который используется в распределенных системах на основе моделей согласования, является отделение собственно вычислительных процессов от механизмов их согласова­ния. Если рассматривать распределенную систему как набор процессов (возмож­но, многопоточных), то вычислительная часть распределен­ной системы образована группой процессов, каждый из которых осуществляет конкретные вычислительные операции, причем эти операции в принципе могут выполняться независимо от других процессов. В этой модели согласующая часть распределенной системы поддерживает все взаимодействие между процессами и организует их взаимную кооперацию. Она образует тот «клей», который связывает воедино деятельность, выполняемую раз­ными процессами. В распределенных системах согласования основное вни­мание уделяется согласованию процессов.

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

Другой тип согласования наблюдается в том случае, если процессы не связа­ны по времени, но связаны по ссылкам. Такой тип согласования называют согласованием через почтовый ящик (mailbox coordination). В этом случае для взаимодействия не нужно, чтобы два взаимодействующих друг с другом процесса выполня­лись одновременно. Вместо этого взаимодействие происходит путем посылки со­общений в почтовый ящик, может быть, используемый совместно. При этом необходимо явно указать адрес почтового ящика, в котором должны храниться сообщения. Это и есть ссылочная связность.

Комбинация связности по времени и несвязности по ссылкам образует груп­пу моделей согласования на встрече (meeting-oriented coordination). В несвязной по ссылкам системе процессы не имеют полной информации друг о друге. Дру­гими словами, когда процесс хочет согласовать свою деятельность с другими про­цессами, он не может обратиться к ним напрямую. Взамен используется метафора встречи, на которой собираются процессы, чтобы скоординировать свою дея­тельность. Модель предполагает, что процессы, участвующие во встрече, выпол­няются одновременно.

Наиболее распространенный вариант согласования – это сочетание несвяз­ных по времени и по ссылкам процессов. Этот вариант представлен генеративной связью (generative communication), которая впервые была реализована в программной системе Linda. Основная идея генеративной связи состоит в том, что набор независимых процессов может использовать разделяемое сохранное пространст­во данных, организуемое с помощью кортежей. Кортежи – это именованные за­писи, содержащие несколько (но, возможно, и ни одного) типизованных полей. Процесс может помещать в разделяемое пространство данных записи любого ти­па (то есть генерировать связующие записи). Для разделения кортежей в соответствии с информацией, которая в них со­держится, достаточно их имен.

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

Примером системы согласования является система Jini («джини») компании Sun Microsystems. Отнесение Jini к системам согласования основано в первую очередь на том, что эта система способна поддерживать гене­ративную связь при помощи Linda-подобной службы под названием JavaSpace. Однако существует множество служб и средств, которые делают Jini больше, чем просто системой согласования.

Jini – это распределенная система, состоящая из разных, но взаимосвязанных элементов. Она жестко привязана к языку программирования Java, хотя многие из ее принципов равно могут быть реализованы и при помощи других языков. Важной частью системы является модель согласования генеративной связи. Jini обеспечивает как временную, так и ссылочную несвязность процессов при помощи системы согласования JavaSpace. JavaSpace – это разделяемое пространство данных, в котором хранятся кортежи. Кортежи представляют собой типизованные наборы ссылок на объекты Java. В одной сис­теме Jini могут сосуществовать несколько пространств JavaSpace.

Кортеж помещается в пространство JavaSpace при помощи операции ЗАПИСЬ, которая сначала выполняет маршалинг кортежа, а затем сохраняет его. Каждый раз при выполнении для кортежа операции ЗАПИСЬ в JavaSpace сохраняется новая подвергнутая маршалингу копия этого кортежа. Можно ссылать­ся на каждую такую копию, как на экземпляр кортежа (tuple instance). Чтобы прочесть экземпляр кортежа, процесс предостав­ляет другой кортеж и использует его как эталон (template), соответствующий считываемым экземплярам кортежа, хранящимся в JavaSpace. Как и любой дру­гой кортеж, эталонный кортеж представляет собой типизованный набор ссылок на объекты. В JavaSpace можно прочитать только экземпляры тех кортежей, ко­торые имеют одинаковый с эталоном тип. Поля в эталонном кортеже также со­держат либо ссылки на реальные объекты, либо значение NULL. Чтобы сопоставить экземпляр кортежа в JavaSpace эталонному кортежу, обыч­ным образом выполняется маршалинг эталонного кортежа, включая маршалинг полей со значением NULL. Для каждого экземпляра кортежа того же типа, что и эталон, производится сравнение (поле за полем) с подвергнутыми маршалингу полями эталонного кортежа. Два поля совпадают, если оба они содержат копии одной и той же ссылки или если поле в эталонном кортеже равно NULL. Экземп­ляр кортежа совпадает с эталонным кортежем, если попарно совпадают соответ­ствующие поля. Когда обнаруживается экземпляр кортежа, совпадающий с эталонным корте­жем (который является частью операции ЧТЕНИЕ), выполняется демаршалинг этого экземпляра, и он возвращается процессу, инициировавшему чтение. Операция ЧТЕНИЕ блокирует вызвавший ее процесс до обнаружения нужного экземпляра кортежа.

JavaSpace образует лишь одну из частей системы Jini, которая существует в виде компактного набора полезных средств и служб, на базе кото­рых можно разрабатывать распределенные приложения. Распределенное прило­жение на базе Jini часто представляет собой свободное сообщество устройств, процессов и служб. Все взаимодействие в существующих системах Jini построено на обращениях RMI языка Java.

Архитектура системы Jini может быть представлена в виде трех уровней. Самый нижний уровень образует инфраструктура. На этом уровне располагаются базовые механизмы Jini, в том числе и те, которые поддерживают взаимодействие посредством обращений RMI языка Java. Службы предоставляются как обычными процессами, так и устройствами, на которых программное обеспечение Jini (в том числе и вир­туальная машина Java) выполняться не может. Поэтому регистрирующие и поис­ковые службы также относятся к инфраструктуре Jini. Второй уровень образуют средства общего назначения, которые дополняют базовую инфраструктуру и могут быть использованы для более эффективной реа­лизации служб. В число этих средств входят подсистемы со­бытий и уведомлений, средства аренды ресурсов и описания стандартных интер­фейсов транзакций. Самый верхний уровень состоит из клиентов и служб. В противоположность остальным двум уровням Jini не определяет состав этого уровня однозначным образом. Актуальная реализация системы поддерживает несколько служб верхнего уровня, среди которых сервер JavaSpace и менеджер транзакций, реализующий интерфейсы транзакций Jini. Программам верхнего уровня, кроме того, нередко разрешается напрямую использовать механизмы инфраструктуры Jini.

Кроме генеративной связи, присущей модели JavaSpace, в число механизмов взаимодействия Jini входит простая подсистема событий и уведомлений. Модель событий Jini относительно проста. Если в рамках объекта происходит со­бытие, которое может быть интересно клиенту, клиенту разрешается зарегистри­ровать себя на этом объекте. Когда факт наступления события будет зафиксирован, то есть когда событие произойдет, объект уведомит об этом зарегистрированного клиента. С другой стороны, клиент может потребовать от объекта, чтобы тот по­слал уведомление о наступлении события в другой процесс. В этом случае объекту пересылается удаленная ссылка на объект-слушатель (listener object), обратный вызов которого можно выполнить при наступлении события (путем обращения RMI языка Java). Регистрация клиента на объекте всегда арендуется. Когда срок аренды истекает, зарегистриро­ванный клиент (или процесс, которому уведомления отправлялись по поруче­нию клиента) перестает получать уведомления. Благодаря аренде регистрация не может сохраниться вечно, например, в результате отказа зарегистрированного клиента.

Уведомление о событии реализуется объектом путем удаленного вызова объекта-слушателя, зарегистрированного для этого события. При следующем наступлении события объект-слушатель вызывается снова. Поскольку система Jini сама по себе не предоставляет никаких гарантий того, что уведомление о со­бытии будет доставлено объекту-слушателю, уведомления обычно имеют поряд­ковые номера, чтобы объект-слушатель имел представление об очередности со­бытий.


2.6. Архитектура серверов приложений

распределенных систем на платформе J2EE


Развитие индустрии MW связано с переходом к трехзвенной архитектуре клиент/сервер, где между клиентом и источником данных размещается промежуточный уровень, реализующий логику приложения. Однако ни одна из рассмотренных категорий MW не удовлетворяет целиком и полностью всем требованиям, которые могут предъявляться к серверу приложений, работающему в современной сложнейшей распределенной корпоративной среде. Брокеры объектных запросов и мониторы транзакций в совокупности с асинхронными механизмами передачи сообщений приближаются к решению этой задачи. Но они, скорее, выступают в роли мощных базовых механизмов для новой категории прикладных систем – серверов приложений, индустрия которых активно развивается.

Разработка серверов приложений нацелена на создание объектно-ориентированных распределенных систем и построение прикладных программ из готовых компонентов.

В сервере приложении на платформе J2EE (Java to Enterprice Edition – «версия Java для предприятий») для поддержки взаимодействия и презентации предназначены сервлеты, а также язык тегов и его интерпретатор, прикладной интерфейс для работы с XML, служба электронной почты, служба аутентификации и авторизации. Поддержка интеграции приложений обеспечивается интерфейсом именования и каталогов, службой сообщений и транзакционным интерфейсом. Поддержка доступа к ресурсам осуществляется компонентами обеспечения связи с базами данных и компонентами подключения архитектур. Система включает и другие прикладные интерфейсы, нужные для интеграции приложений.

Целью поддержки прикладного слоя является создание единого окружения для всех видов прикладной логики, работающей в глобальной сети и без нее. В комплексе J2EE компоненты прикладной логики размещаются на серверной стороне и обеспечивает функциональность, специфическую для данного приложения, например, подготовку прайс-листов в ответ на запрос покупателя о покупке. В состав некоторого приложения могут входить несколько компонентов прикладной логики одного из трех типов, в зависимости от метода, выбранного для управления состоянием и сохранностью. Сессионный вариант управляет сессией с клиентом. Имеются модификации, отслеживающие состояния и не делающие этого. Если состояния не отслеживаются, один и тот же компонент может использоваться для работы с разными клиентами. Объектовый вариант продолжает существование за пределами одной сессии с клиентом. Он имеет состояния, хранящиеся в базе данных или в другой сохранной памяти. Разработчик может сам писать SQL-запросы или другие команды, чтобы запомнить состояние в базе данных, а может управлять сохранностью автоматически. Вариант с управлением сообщениями обеспечивает возможность асинхронного взаимодействия с клиентом.

Компоненты прикладной логики могут помещаться в контейнер, предоставляющий функциональность по поддержке транзакционности, сохранности и безопасности, общую для разных типов компонентов. Контейнер управляет транзакциями, руководствуясь свойствами, приписанными компонентам прикладной логики во время конфигурирования. Привязка к компоненту прикладной логики производится с помощью службы именования и каталогов. Используя эту службу, клиенты могут привязываться к серверу, зная только имя объекта. В состав сервера J2EE входит транзакционный прикладной программный интерфейс. Для совместимости с системами, построенными на основе спецификации CORBA, в сервер J2EE добавлен набор транзакционных интерфейсов.

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

Язык тегов позволяет вставлять в обычные документы HTML (Hyper Text Markup Language – «гипертекстовый язык разметки») дополнительные теги, расширяющие возможности стандартных страниц. С помощью тегов можно задавать параметры страниц HTML, включать в страницы файлы, адреса которых указываются в тегах, выполнять определения объектов Java, вычислять значения выражений Java и выполнять встроенные фрагменты программ Java.

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


1   2   3   4   5   6   7   8   9

Похожие:

Контрольные вопросы и задания iconМетодические указания и контрольные задания для студентов-заочников По дисциплине: «Технология и организация строительного производства»
В методических указаниях приведены рекомендации по изучению программного материала, вопросы для самоконтроля, задания на контрольные...

Контрольные вопросы и задания iconМетодические указания и контрольные задания для студентов заочной формы обучения по специальности: 080110 «Экономика и бухгалтерский учет» 2006
Почтовая связь. Методические указания содержат программу дисциплины, вопросы для самоконтроля по разделам, задания для контрольной...

Контрольные вопросы и задания iconТехнологического оборудования программа, контрольные задания и
Программа, контрольные задания и методические указания для учащихся заочного отделения специального 2-36 01 03 «Технологическое оборудование...

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

Контрольные вопросы и задания iconМетодическая разработка по дисциплине «Публичные финансы»
«Финансы и финансовые институты» и состоит из двух частей. Первая часть – «Семинарские занятия и самостоятельная работа» включает:...

Контрольные вопросы и задания iconКонтрольные вопросы и задания (29)
Гладкий Ю. Н., Доброскок В. А., Семенов С. П. Социально-экономическая география России

Контрольные вопросы и задания iconКонтрольные вопросы и задания 34
Техника безопасности при проведении занятий в кабинете вычислительной техники 174

Контрольные вопросы и задания iconКонтрольные вопросы и задания
Оцените пражурналистские явления в античном мире, средневековой Ев­ропе и допетровской России

Контрольные вопросы и задания iconФизические основы электроники. Преобразовательная техника программа
Методические указания предназначены для студентов специальности «Электропривод и автоматика технологических процессов и комплексов»....

Контрольные вопросы и задания iconКонтрольные вопросы и пр Тема: Общая характеристика обмена веществ. Ферментативный катализ Вопросы для самостоятельной
Содержание срс с методическими рекомендациями для студентов (тема, план, контрольные вопросы и пр.)

Разместите кнопку на своём сайте:
Библиотека


База данных защищена авторским правом ©lib.znate.ru 2012
обратиться к администрации
Библиотека
Главная страница