Организация связи с использованием удаленных объектов

⇐ ПредыдущаяСтр 10 из 16Следующая ⇒

Объектно-ориентированная технология в настоящее время широко приме- няется при разработке приложений, в том числе и распределенных.

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

Это позволяет заменять или изменять объекты, оставляя интерфейс неизменным.

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

Основными достоинствами данного подхода стали:

  простота разработки распределенных приложений по сравнению с класси- ческим клиент/серверным подходом;

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

  возможность отделения интерфейса удаленного объекта от его непосред- ственной реализации. Удаленный объект представляет собой некоторые данные, совокупность которых определяет его состояние. Это состояние можно изменять путем вы- зова его методов.

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

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

В момент, когда клиент начинает использовать удаленный объект, на сто- роне клиента создается клиентская заглушка, называемая посредником (англ. proxy).

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

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

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

Промежуточная среда на стороне сервера десериализует параметры и передает их за- глушке на стороне сервера, которую называют каркасом (skeleton) или, как и в удаленном вызове процедур, заглушкой.

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

При использовании удаленных объектов проблемными являются вопросы о времени их жизни:

  в какой момент времени создается экземпляр удаленного объекта; в течение какого промежутка времени он существует. Для описания жизненного цикла в системах с удаленными объектами ис- пользуются два дополнительных понятия:

  активация объекта: процесс перевода созданного объекта в состояние об- служивания удаленного вызова, то есть связывания его с каркасом и по- средником.

  деактивация объекта: процесс перевода объекта в неиспользуемое состоя- ние.

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

Распределенное приложение, разработанное на базе технологии Java RMI, состоит из двух отдельных программ: клиента и сервера.

Серверное приложе- ние создает удаленный объект, публикует ссылки на него и ожидает, когда кли- енты произведут вызов метода данного удаленного объекта.

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

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

Достоинствами использования технологии Java RMI для разработки рас- пределенного приложения можно назвать возможность разрабатывать систему целиком основываясь на объектно-ориентированной концепции, не погружаясь в разработку собственных протоколов взаимодействия между распределенными компонентами систем, а также кроссплатформенность, предоставляемую вир- туальной машиной Java.

К недостаткам данного подхода можно отнести:

  строгую ограниченность данной технологии платформой Java;

  необходимость обработки соединений между распределенными компонен- тами приложения ограничивает масштабируемость используемого подхо- да.

CORBA

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

CORBA (Common Object Request Broker Architecture – общая архитектура брокера объектных запросов) – это технология разработки распределенных приложений, ориентированная на интеграцию распределенных изолированных систем.

В начале 1990-х гг. ночным кошмаром разработчиков было обеспечение общения программ, выполняемых на разных машинах, особенно, если исполь- зовались разные аппаратные средства, операционные системы и языки про- граммирования. Программистам приходилось использовать технологию соке- тов и самостоятельно реализовывали весь стек протоколов взаимодействия, ли- бо их программы вовсе не взаимодействовали (другие ранние средства проме- жуточного программного обеспечения были ограничены средой C и Unix и не подходили для использования в неоднородных средах).

Для решения данной проблемы в 1989 г. был создан консорциум OMG (Object Management Group), основной задачей которого стала разработка и про- движение объектно-ориентированных технологий и стандартов. Это некоммер- ческое объединение, разрабатывающее стандарты для создания корпоративных платформо-независимых приложений. Концептуальной инфраструктурой, на которой базируются все специфика- ции OMG, является Object Management Architecture (OMA).

В состав OMA вхо- дят разнообразные стандартизованные или в настоящий момент стандартизиру- емые OMG сервисы, программные образцы и шаблоны, язык определения ин- терфейсов распределенных объектов IDL (Interface Definition Language), стан- дартизованные или стандартизируемые отображения IDL на языки программи- рования и, наконец, объектная модель CORBA.

Главной особенностью CORBA является использование компонента ORB (Object Resource Broker – брокер ре- сурсов объектов) для создания экземпляров объектов и вызова их методов. Данный компонент формирует «мост» между приложением и инфраструктурой CORBA.

В 1997 г. консорциум OMG опубликовал спецификацию CORBA 2.0. В ней определялись стандартный протокол и отображение для языка C++, а в 1998 г. было определено отображение для Java.

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

Технология CORBA

Основные компоненты, составляющие архитектуру CORBA, представлены на рисунке 14.

Технологический стандарт CORBA определяет язык IDL, при- меняемый для унифицированного описания интерфейсов распределенных объ- ектов, и его отображения на языки Ada, C, C++, Java, Python, COBOL, Lisp, PL/1 и Smalltalk.

Для преобразования описания интерфейса на языке IDL на требуе- мый язык программирования используется специальный компилятор.

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

Главной особенностью CORBA является использование компонента ORB (Object Resource Broker – брокер ресурсов объектов) для создания экземпляров объектов и вызова их методов.

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

Для обес- печения взаимодействия между ORB используется протокол GIOP (General Inter- ORB Protocol – общий протокол для коммуникации между ORB) [42].

Наиболее распространенной реализацией данного протокола является протокол IIOP (Internet Inter-ORB Protocol – протокол взаимодействия ORB в сети интер- нет), обеспечивающий отображение сообщений GIOP на стек протоколов TCP/IP.

Изначально, технология CORBA ориентирована на предоставление гото- вой проблемно-ориентированной инфраструктуры для создания РВС в рамках определенной проблемной области.

Для этого, в состав CORBA включают набор стандартных объектных сервисов и общих средств. Спецификация CORBA предусматривает также ряд стандартизованных сервисов (CORBA Services) и горизонтальных и вертикальных Общих Средств (Common Facilities).

Сервисы представляют собой обычные CORBA-объекты со стандартизованны- ми (и написанными на IDL) интерфейсами. К таким сервисам относится, например, сервис имен NameService, сервис сообщений, позволяющий CORBA- объектам обмениваться сообщениями, сервис транзакций, позволяющий CORBA-объектам организовывать транзакции.

В реальной системе не обяза- тельно должны присутствовать все сервисы, их набор зависит от требуемой функциональности. На сегодня разработано 14 объектных сервисов.

Между объектными сервисами и общими средствами CORBA нет четкой границы.

Последние тоже представляют собой CORBA-объекты со стандарти- зованными интерфейсами.

Общие средства делятся на горизонтальные (общие для всех прикладных областей) и вертикальные (для конкретной прикладной области).

Например, разработаны общие средства для медицинских организа- ций, для ряда производственных сфер и т.п.

Разработка на основе CORBA

Процесс разработки приложения с использованием технологии CORBA состоит из следующих 4-х этапов:

1. Определение интерфейса на IDL.

2. Обработка IDL для создания кода заглушки и скелетона.

3. Создание кода реализации объекта (сервер).

4. Создание кода использования данного объекта (клиент).

Язык определения IDL позволяет независимо от используемого языка про- граммирования создать универсальное описание интерфейса будущей системы. Созданный на IDL код должен специальным компилятором преобразовы- ваться в код интерфейса объекта на требуемом языке программирования. После чего, на клиенте автоматически генерируется заглушка, преобразующая вызовы методы данного интерфейса в обращения к ORB.

На сервере программист на основе сгенерированного интерфейса создает собственную реализацию данного класса. Скелетон автоматизирует получение и обработку удаленного вызова методов, поступающих через ORB.

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

  использование IDL для описания интерфейсов позволяет разрабатывать программные компоненты независимо от языка программирования и базо- вой операционной системы;

  поддержка богатой инфраструктуры распределенных объектов;

  прозрачность вызова удаленных объектов.

Однако программные решения на базе технологии CORBA редко выходят за рамки отдельных предприятий.

Разработка крупномасштабных меж- организационных систем на базе технологии CORBA сопряжена со следующи- ми трудностями:

  плохая совместимость различных реализаций технологии CORBA от раз- личных поставщиков;

  проблемы взаимодействия узлов CORBA через Интернет;

  несогласованность многих архитектурных решений CORBA и отсутствие компонентной модели, которая могла бы значительно упростить разработ- ку.

На смену технологии CORBA, пришли стандартизованные протоколы веб- сервисов, такие как XML, WSDL, SOAP и др. В настоящее время CORBA ис- пользуется для реализации узкого круга унаследованных приложений.

3.2 Трехуровневая модель

С середины 90-х годов прошлого века признание специалистов получила трехзвенная архитектура «Клиент – сервер», которая разделила информационную систему по функциональным возможностям на три отдельных компонента: логика представления, бизнес-логика и логика доступа к данным.

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

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

Такой интерфейс можно реализовать с помощью стандартных средств Web-технологии - браузера, CGI и Java.

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

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

Сервер приложений – это программное обеспечение, являющееся промежуточным слоем между клиентом и сервером (рисунок 35).

Рисунок 35 - Сервер приложений

Существует несколько категорий продуктов промежуточного слоя:

- Message orientated – яркие представители MQseries и JMS;

- Object Broker – яркие представители CORBA и DCOM;

- Component based – яркие представители.NET и EJB.

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

Так как бизнес-логика хранится на сервере приложений, то при каких-либо изменениях в отчетности или расчетах клиентские программы никоим образом не затрагиваются.

Существует несколько серверов приложений от таких знаменитых компаний как Sun Microsystem, Borland, IBM, Oracle и каждый из них отличается набором предоставляемых сервисов (производительность в данном случае учитывать не будем).

Эти сервисы облегчают программирование и развертывание приложений масштаба предприятия.

Обычно сервер приложений предоставляет следующие сервисы:

- WEB Server – чаще всего включают в поставку самый популярный и мощный Apache;

- WEB Container – позволяет выполнять JSP и сервлеты.

Для Apache таким сервисом является Tomcat;

- CORBA Agent – может предоставлять распределенную директорию для хранения CORBA объектов;

- Messaging Service – брокер сообщений;

- Transaction Service – уже из названия понятно, что это сервис транзакций;

- JDBC – драйвера для подключения к базам данных, ведь именно серверу приложений придется общаться с базами данных и ему нужно уметь подключаться к используемой в вашей компании базе;

- Java Mail – данный сервис может предоставлять сервис к SMTP;

- JMS (Java Messaging Service) – обработка синхронных и асинхронных сообщений;

- RMI (Remote Method Invocation) - вызов удаленных процедур.

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

Для разработки этих программ можно использовать как Common Gateway Interface (CGI), так и более современную технологию Java.

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

Из всего вышесказанного можно сделать вывод, что двухуровневая архитектура сильно уступает многоуровневой архитектуре, поэтому в настоящее время используется только многоуровневая архитектура «Клиент – сервер», в которой различают три модификации - RDA, DBS и AS.

⇐ Предыдущая 5 6 7 8 91011 12 13 14 Следующая ⇒