В чем заключается сущность объектно – ориентированного подхода к организации распределенной обработки информации?

21.

Поясните понятия процедур маршалинга и демаршалинга.

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

Противоположный процесс называется демаршалингом (также называемый десериализацией).

Маршалинг задействуется при использовании различных механизмов RPC, где есть необходимость в передаче данных между процессами и потоками. Переход от неуправляемого типа в тип CLR, как, например, в процессах P/Invoke, используемых в платформе .NET Framework, является подходящим примером, демонстрирующим применение маршалинга.

Кроме того, маршалинг широко используется в скриптах и приложениях, применяющих технологии XPCOM, поставляемой в составе Mozilla application framework. Браузер Mozilla Firefox — одно из самых известных приложений, созданных с применением этой платформы, что позволило скриптовым языкам использовать технологию XPCOM через Cross-Platform Connect.

В Delphi 2010 процесс сериализации и десериализации обрабатывается соответсвенно Маршалером and Демаршалером.

Для любого объекта в Delphi встроенным форматом для сериализации является JSON.
За сериализацию объектов в JSON отвечают 2 основных класса, представленные в модуле DBXJSONReflect:
- TJSONMarshal
- TJSONUnMarshal.

22.

24.

21.

Поясните понятия процедур маршалинга и демаршалинга.

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

Противоположный процесс называется демаршалингом (также называемый десериализацией).

Маршалинг задействуется при использовании различных механизмов RPC, где есть необходимость в передаче данных между процессами и потоками. Переход от неуправляемого типа в тип CLR, как, например, в процессах P/Invoke, используемых в платформе .NET Framework, является подходящим примером, демонстрирующим применение маршалинга.

Кроме того, маршалинг широко используется в скриптах и приложениях, применяющих технологии XPCOM, поставляемой в составе Mozilla application framework. Браузер Mozilla Firefox — одно из самых известных приложений, созданных с применением этой платформы, что позволило скриптовым языкам использовать технологию XPCOM через Cross-Platform Connect.

В Delphi 2010 процесс сериализации и десериализации обрабатывается соответсвенно Маршалером and Демаршалером.

Для любого объекта в Delphi встроенным форматом для сериализации является JSON.
За сериализацию объектов в JSON отвечают 2 основных класса, представленные в модуле DBXJSONReflect:
- TJSONMarshal
- TJSONUnMarshal.

22.

В чем заключается сущность объектно – ориентированного подхода к организации распределенной обработки информации?

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

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

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

При выполнении клиентом «привязки» к распределенному объекту в адресное пространство клиента загружается реализация интерфейса объекта, называемая заместителем (proxy). Заместитель клиента аналогичен клиентскому переходнику в механизме RPC. Он выполняет маршалинг параметров в сообщения при обращении к методам, демаршалинг данных из ответных сообщений с результатами обращения к методам, передачу результатов клиенту. Сами же объекты находятся на сервере и предоставляют необходимые клиентской системе интерфейсы. Входящий запрос на обращение к методу сначала попадают в так называемый серверный каркас, или скелетон (skeleton), аналогичный серверному переходнику в RPC. Cерверный каркас преобразует входящий запрос в обращение к методу через интерфейс объекта, находящегося на сервере. Каркас также отвечает за маршалинг параметров в ответных сообщениях и их пересылку заместителю клиента. Если объект физически распределен по нескольким вычислительным машинам, то это скрывается от клиентов за интерфейсами объектов.

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

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

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

Клиент, осуществив связь с объектом, может через заместителя объекта обратиться к методам объекта. Таким образом при объектно-ориентированном подходе к распределенной обработке информации реализуется механизм так называемого удаленного обращения к методам (Remote Method Invocation – RMI). RMI и RPC схожи в организации маршалинга и передачи параметров, описание интерфейсов объектов проводится на языке определения интерфейсов. Основное различие между RMI и RPC состоит в том, что RMI главным образом поддерживает внутрисистемные ссылки на объекты. В RMI отпадает необходимость в клиентских и серверных переходниках общего назначения. Вместо них используются значительно более удобные в работе и специфические для объектов средства – клиентский заместитель объекта и серверный каркас.

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

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

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

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

Стандарт CORBA (Common Object Request Broker Architecture – «обобщенная архитектура брокера объектных запросов»), продвигаемый рабочей группой по управлению объектами консорциума OMG (Object Management Group), – это архитектура и спецификация для создания и управления объектно-ориентированными приложениями, распределенными в вычислительной сети. К настоящему время выработано несколько версий стандарта CORBA. Спецификацией не определяются ни языки программирования разрабатываемых объектно-ориентированных приложений, ни операционные системы, в которых они должны работать.

Система, подчиняющаяся спецификации CORBA, состоит из трех основных частей: брокера объектных запросов ORB (Object Request Broker), набора служб (CORBAServices), доступных с помощью стандартизованного прикладного программного интерфейса, и набора средств и инструментов. ORB является основой каждого процесса на клиенте и на сервере в любой распределенной системе типа CORBA. Брокеры объектных запросов отвечают за поддержание связи между объектами и их клиентами, скрывая проблемы распределенности и разнородности системы. ORB содержит базовые функции взаимодействия объектов. Эти функции гарантируют обращение к серверу объектов и возвращение клиенту ответов сервера. Службы предоставляют функции сохранности, управления жизненным циклом, безопасности и многие другие. Принципиальная схема организации системы CORBA показана на рис. 2.3.

Укрупненная последовательность действий брокера ORB при реализации вызова метода удаленного объекта состоит из следующих этапов:

а) найти удаленный объект;

б) активизировать модуль, содержащий искомый объект, если таковой еще не активизирован;

в) передать аргументы удаленному объекту;

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

д) вернуть клиенту информацию или исключение, если вызов удаленного метода оказался неуспешным.

Интерфейсы объектов описываются на языке описания интерфейсов IDL. В дополнение к описанию методов, в отличие от систем на базе RPC, язык IDL CORBA поддерживает множество объектно-ориентированных концепций, например, наследование и полиморфизм. Запись на IDL передается компилятору, который формирует заместитель объекта, скрывающий распределенность, и каркас (скелетон). Для клиента вызовы выглядят не удаленными, а локальными. Программа заместителя объекта содержит в себе описание методов, предоставляемых реализацией объекта, она загружается вместе с программой клиента. Каркас защищает сервер от проблем распределенности, поэтому сервер может разрабатываться так, как если бы вызовы к нему поступали из локального окружения. Все, что требуется знать программисту, это IDL-интерфейс сервера. Семантика интерфейсов методов не формализуется, она описывается другими средствами, например, в виде комментариев или в составе сопроводительной документации. Стандарт CORBA 3 поддерживает IDL для C, C++, Java, Smalltalk, Lisp, Ada и других языков.