Отсрочка запросов вызова для удаленных объектов

Группа изобретений относится к области вычислительной техники. Техническим результатом является повышение надежности при обработке запросов при осуществлении доступа к объектам, размещенным на сервере. Способ содержит этапы, на которых принимают запросы вызова, причем каждый запрос вызова - от прокси-объекта прокси-класса приложения, который соответствует удаленному объекту класса удаленного объекта; для каждого принятого запроса вызова определяют, допускает ли запрос вызова отсрочку; если допускает - сохраняют запрос вызова, если не допускает - отправляют на сервер сообщение запроса вызова, включающее каждый ранее неотправленный сохраненный запрос вызова и принятый запрос вызова, при этом сообщение запроса вызова указывает очередность, в которой были приняты запросы вызова; принимают от сервера сообщения ответа вызова, причем каждое сообщение ответа вызова является ответным на сообщение запроса вызова, которое включало в себя один или более запросов вызова; и для каждого ответа вызова из принятого сообщения ответа вызова, когда ответ вызова включает в себя выходной параметр, извлекают этот выходной параметр из ответа вызова и предоставляют приложению указание того, что был принят ответ вызова, и любой извлеченный выходной параметр. 3 н. и 16 з.п. ф-лы, 17 ил.

 

УРОВЕНЬ ТЕХНИКИ

[0001] Основанные на облаке услуги часто предоставляются через приложения, которые исполняются через веб-браузер. Чтобы разработать такое приложение, программист должен разработать приложение, которое должно исполняться веб-браузером клиента и которое осуществляет доступ к услугам сервера облачного центра хранения и обработки данных (датацентра). Приложение (или код клиента), как правило, предоставляет интерфейс пользователя, через который пользователь может осуществлять доступ к возможностям приложения. Например, если приложение является текстовым процессором, тогда приложение визуально воспроизводит содержимое редактируемого документа, строку меню для доступа к возможностям текстового процессора (например, открыть документ и вставить подстрочное примечание) и т.д. Редактируемый документ хранится на сервере. Таким образом, когда пользователь запрашивает открытие документа, приложение отправляет запрос открытия серверу и принимает копию, по меньшей мере, фрагмента документа. Приложение визуально воспроизводит содержимое документа. Когда пользователь вносит изменение в документ, приложение может обновлять воспроизводимое содержимое и отправлять сообщение серверу. Затем сервер меняет документ. Связь между клиентом и сервером, как правило, основана на модели Передачи Репрезентативного Состояния («REST») или RESTful, как например сообщениях запроса Протокола Передачи Гипертекста («HTTP») (например, метод GET) и сообщениях ответа.

[0002] Такие приложения, как правило, написаны на JavaScript, так как большая часть браузеров поддерживает исполнение приложений JavaScript. Код сервера наоборот, как правило, написан на языках программирования отличных от JavaScript, таких как C# или C++, по причинам эффективности, так как JavaScript является интерпретируемым языком, а C# и C++ компилируются в исполняемые файлы. JavaScript и C# и C++ являются объектно-ориентированными языками программирования. Объектно-ориентированный язык программирования поддерживает модель программирования, в которой программа указывает классы, которые определяют типы объектов, экземпляр которых может быть создан. Класс определяет данные-члены и методы (также упоминаются как функции-члены) для объектов этого класса. Каждый метод имеет сигнатуру, которая указывает имя метода, типы входных параметров, которые должны быть переданы в метод, и типы выходных параметров, которые должны быть возвращены методом. Например, класс документа может быть определен включающим в себя методы для открытия документа, модификации документа и сохранения документа. Во время исполнения приложения, после того как создается экземпляр объекта определенного класса, приложение может вызывать метод объекта посредством указания ссылки на объект, указания метода для вызова и входных параметров (если есть), которые должны быть переданы в метод. Когда метод завершается, метод возвращает выходные параметры (если есть).

[0003] Такие приложения исторически осуществляли доступ к услугам сервера, используя интерфейс веб-услуги, который определяется Языком Описания Веб-услуг («WSDL») или используя некоторый другой тип механизма вызова удаленных процедур («RPC»). К сожалению, присутствует небольшая поддержка для объектно-ориентированных RPC, также именуемых вызовами удаленных методов («RMI»), из таких приложений к серверам. В результате такие приложения часто не используют объектно-ориентированный подход при осуществлении доступа к объектам, размещенным на сервере.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

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

[0006] Предоставляется система для исполнения приложения на клиенте, чтобы отправлять запросы вызова удаленным объектам сервера. Каждый запрос вызова формируется, когда приложение вызывает прокси прокси-класса приложения, соответствующего удаленному объекту класса удаленного объекта. Для каждого запроса вызова, когда запрос вызова допускает отсрочку, система сохраняет запрос вызова. Когда запрос вызова не допускает отсрочку, система отправляет серверу сообщение запроса вызова, которое включает в себя каждый не отправленный ранее хранящийся запрос вызова и текущий запрос вызова. Система принимает сообщения ответа вызова от сервера. Для каждого ответа вызова принятого сообщения ответа вызова система предоставляет приложению указание того, что был принят ответ вызова.

[0007] Это краткое изложение сущности изобретения приведено для ознакомления с подборкой концепций в упрощенной форме, которые в дальнейшем описываются ниже в Подробном Описании. Данное краткое изложение сущности изобретения не предназначено ни для того, чтобы идентифицировать ключевые признаки или неотъемлемые признаки заявленного изобретения, ни для использования с целью ограничения объема заявленного изобретения.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

[0008] Фигура 1 является структурной схемой, которая иллюстрирует структуры данных приложения и компонента сервера в некоторых вариантах осуществления.

[0009] Фигура 2 является блок-схемой, которая иллюстрирует обработку метода прокси, который синхронно вызывается в некоторых вариантах осуществления.

[0010] Фигура 3 является блок-схемой, которая иллюстрирует обработку компонента приема запроса компонента сервера в некоторых вариантах осуществления.

[0011] Фигура 4 является блок-схемой, которая иллюстрирует обработку метода извлечения параметров класса объекта ответа для объекта ответа компонента клиента в некоторых вариантах осуществления.

[0012] Фигура 5 является блок-схемой, которая иллюстрирует обработку метода хранения параметров класса объекта ответа для объекта ответа клиентского компонента в некоторых вариантах осуществления.

[0013] Фигура 6 является блок-схемой, иллюстрирующей обработку метода поиска ID класса объекта таблицы ID в некоторых вариантах осуществления.

[0014] Фигура 7 является блок-схемой, которая иллюстрирует обработку метода поиска ссылки объекта таблицы ID в некоторых вариантах осуществления.

[0015] Фигура 8 является блок-схемой, которая иллюстрирует обработку метода добавления записи объекта таблицы ID, которому передается ссылка в некоторых вариантах осуществления.

[0016] Фигура 9 является блок-схемой, которая иллюстрирует обработку метода добавления записи объекта таблицы ID, которому передается запись в некоторых вариантах осуществления.

[0017] Фигура 10 является структурной схемой, которая иллюстрирует вариант осуществления системы OORPC, которая поддерживает размещение в одноранговым узле удаленных объектов в некоторых вариантах осуществления.

[0018] Фигура 11 является структурной схемой, которая иллюстрирует структуры данных, которые поддерживают синхронизацию значения свойств посредством системы OORPC в некоторых вариантах осуществления.

[0019] Фигура 12 является блок-схемой, которая иллюстрирует обработку компонента получения значений свойства компонента сервера в некоторых вариантах осуществления.

[0020] Фигура 13 является блок-схемой, которая иллюстрирует обработку компонента хранения значений свойства компонента клиента в некоторых вариантах осуществления.

[0021] Фигура 14 является блок-схемой, которая иллюстрирует генератор кода системы OOPRC для автоматического формирования кода для прокси-классов в некоторых вариантах осуществления.

[0022] Фигура 15 является блок-схемой, которая иллюстрирует обработку компонента обработки свойств прокси генератора кода в некоторых вариантах осуществления.

[0023] Фигура 16 является блок-схемой, которая иллюстрирует обработку компонента отправки запроса компонента клиента в некоторых вариантах осуществления.

[0024] Фигура 17 является блок-схемой, которая иллюстрирует обработку компонента приема запроса компонента сервера в некоторых вариантах осуществления.

ПОДРОБНОЕ ОПИСАНИЕ

[0025] Предложены способ и система для автоматического формирования кода для приложения, исполняемого клиентом, чтобы осуществлять доступ к объектам, которые размещены удаленно на сервере или другом удаленном устройстве объектно-ориентированным образом. Понятие «клиент» относится к вычислительному устройству и понятие «сервер» относится к вычислительному устройству. В некоторых вариантах осуществления система Объектно-Ориентированного Вызова Удаленных Процедур («OORPC») вводит определение интерфейсов для классов удаленного объекта для объектов, которые размещаются удаленно на сервере («удаленные объекты»). Для каждого класса удаленного объекта система OOPRC автоматически формирует прокси-класс, который служит в качестве прокси для класса удаленного объекта. «Прокси» является объектом, методы которого первоначально отправляют сообщения запроса вызова серверу, на котором размещается соответствующий удаленный объект. Как правило, существует взаимно-однозначное соответствие между прокси и удаленным объектом. Прокси-класс имеет точно такой же интерфейс (например, точно такие же методы и сигнатуры метода), как и у соответствующего класса удаленного объекта, но с кодом, который отличается от кода класса удаленного объекта. Для каждого метода прокси-класса система OORPC формирует код для этого метода, который, когда вызывается, отправляет сообщение запроса вызова серверу, на котором размещается удаленный объект, соответствующий прокси прокси-класса. Сообщение запроса вызова идентифицирует удаленный объект, метод и любые входные параметры, передаваемые в метод. Система OORPC также формирует код для метода так, что после того как сообщение ответа вызова принимается от удаленного устройства, возвращает из вызова метода любые выходные параметры, которые были идентифицированы в сообщении ответа вызова. В качестве альтернативы, если вызов метода является асинхронным вызовом, то система OORPC включает компонент клиента, чтобы обрабатывать сообщение ответа вызова, которое может не быть частью метода, а наоборот частью метода обратного вызова, который должен быть вызван, чтобы просигнализировать приложению то, что исполнение метода завершено.

[0026] В некоторых вариантах осуществления система OORPC предоставляет компонент клиента для приложения, который привязывает каждый прокси к его соответствующий удаленный объект. Приложение может иметь прокси создания, соответствующий удаленному объекту создания, который используется для создания экземпляра удаленных объектов. Каждый метод прокси создания может быть вызван, чтобы создавать экземпляр удаленного объекта определенного класса удаленного объекта. Каждый метод отправляет сообщение запроса вызова компоненту сервера, упоминаемому как «боковик», чтобы вызывать соответствующий метод на удаленном объекте создания для создания экземпляра удаленного объекта класса удаленного объекта. Каждый метод также создает экземпляр прокси для удаленного объекта и возвращает ссылку на прокси. Например, прокси создания может иметь метод создания документа, который отправляет компоненту сервера сообщение запроса вызова, запрашивающее вызов метода создания документа удаленного объекта создания, чтобы создать экземпляр удаленного объекта документа. Созданному экземпляру удаленного объекта документа может быть назначен идентификатор объекта (либо приложением, либо кодом сервера). Метод создания документа прокси создания также создает экземпляр прокси-документа, соответствующий удаленному объекту документа, и привязывает ссылку к прокси-документу (например, адресу прокси-документа) в идентификаторе объекта. Метод создания документа прокси создания затем возвращает ссылку на прокси-документ. Когда приложение впоследствии вызывает метод прокси-документа, как указано посредством ссылки, этот метод использует свою ссылку, чтобы найти идентификатор объекта удаленного объекта документа. Это метод затем отправляет компоненту сервера сообщение запроса вызова, как описано выше, которое включает в себя идентификатор объекта, чтобы идентифицировать удаленный объект документа для компонента сервера.

[0027] Когда компонент сервера принимает сообщение запроса вызова, компонент сервера извлекает из сообщения запроса вызова идентификатор объекта, идентификатор метода и любые входные параметры. Компонент сервера находит ссылку на удаленный объект, который идентифицируется посредством идентификатора объекта, и вызывает передачу входных параметров идентифицированному методу. Когда метод осуществляет возврат, компонент сервера отправляет сообщение ответа вызова клиенту, которое включает в себя идентификатор объекта, идентификатор метода и любые выходные параметры.

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

[0029] В некоторых вариантах осуществления система OORPC может не отправлять запросы вызова до тех пор, пока не будет удовлетворен критерий отправки сообщения запроса вызова. Когда критерий отправки сообщения запроса вызова удовлетворяется, система OORPC отправляет сообщение запроса вызова, которое включает в себя каждый запрос вызова, который еще не был отправлен. Например, методы прокси-классов могут быть обозначены как допускающие отсрочку, так и не допускающие отсрочку (например, через метаданные, ассоциированные с интерфейсом для класса удаленного объекта). Когда приложение вызывает метод, который допускает отсрочку, система OORPC формирует запрос вызова, который включает в себя идентификатор объекта, идентификатор метода и любые входные параметры, и ставит запрос вызова в очередь. Когда приложение вызывает метод, который не допускает отсрочку, система OORPC отправляет сообщение запроса вызова, которое включает в себя стоящие в очереди запросы вызова и запрос вызова для текущего вызова. Критерий отправки сообщения запроса вызова может быть удовлетворен, когда вызывается метод, который не допускает отсрочку. Критерий отправки сообщения запроса вызова аналогичным образом может быть удовлетворен, когда запрос вызова стоял в очереди в течение определенного периода, когда в очереди стоит определенное число запросов вызовы, когда приложение предписывает, что сообщение запроса вызова должно быть отправлено и/или т.д.

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

[0031] В некоторых вариантах осуществления система OORPC обеспечивает поддержку для хранения значений свойств удаленных объектов локально на клиенте. Система OORPC формирует прокси-класс для класса удаленного объекта, система OORPC формирует получающие методы («методы получения») для свойств по-другому, чем для других методов. Система OORPC формирует получающий метод, который, вместо отправки сообщения запроса вызова серверу, чтобы найти значение свойства, находит локально хранящееся значение для свойства и возвращает значение. Чтобы гарантировать то, что локально хранящееся значение для свойства прокси синхронизировано со значением, которое хранится в соответствующем удаленном объекте, компонент сервера может прикреплять к каждому сообщению ответа вызова обновление свойства для каждого свойства удаленного объекта, значение которого изменилось с момента, когда было отправлено последнее сообщение ответа вызова. Компонент сервера может сохранять список значений, которые были последними отправленными для каждого свойства, и при отправке сообщения ответа вызова, он может вызывать получающий метод для каждого свойства каждого удаленного объекта, чтобы идентифицировать значения, которые изменились.

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

[0033] Фигура 1 является структурной схемой, которая иллюстрирует структуры данных приложения и компонента сервера в некоторых вариантах осуществления. Клиент 110 исполняет приложение 111, а сервер 120 исполняет компонент 121 сервера. Приложение и компонент сервера представлены в качестве псевдокода. Во время инициализации компонент 119 клиента системы OORPC, исполняемый в клиенте, может создавать экземпляр 113 таблицы ID, а компонент сервера, который является компонентом системы OORPC, может создавать экземпляр объекта 123 таблицы ID. Объекты таблицы ID предоставляют методы для хранения и поиска привязок идентификаторов объекта прокси и удаленных объектов в их соответствующих ссылках в таблице ID объектов таблицы ID. Приложение создает экземпляр прокси 112 создания, а компонент сервера создает экземпляр соответствующего удаленного объекта 122 создания. Компонент клиента добавляет в объект 113 таблицы ID привязку идентификатора объекта (например, 1) для прокси создания в ссылке (например, адресе) на прокси создания («S»), а компонент сервера добавляет в объект 123 таблицы ID привязку идентификатора объекта для удаленного объекта создания в ссылке на удаленный объект создания. Затем компонент сервера ждет приема запросов вызова от клиента. Идентификатор объекта для прокси клиента и идентификатор объекта для соответствующего удаленного объекта сервера имеют одно и то же значение.

[0034] Чтобы создать удаленный объект класса удаленного объекта, приложение вызывает метод прокси создания для создания удаленных объектов класса удаленного объекта. Например, если класс удаленного объекта назван «X», то приложение может вызывать метод createX прокси создания, чтобы создавать удаленный объект класса X удаленного объекта. Метод createX прокси создания отравляет серверу сообщение запроса вызова («req»), которое включает в себя идентификатор объекта удаленного объекта создания («req.ID»), идентификатор метода у метода createX («req.method») и любые входные параметры (req.inparm»). Компонент клиента может создавать экземпляр объекта 117 запроса, чтобы хранить данные сообщения запроса вызова, который долен быть отправлен, и объект 118 ответа, чтобы хранить данные сообщения ответа вызова, которое принимается. Аналогичным образом компонент сервера может создавать экземпляр объекта 127 запроса, чтобы хранить данные сообщения запроса вызова, которое принимается, и объект 128 ответа, чтобы хранить данные сообщения ответа вызова, которое должно быть отправлено.

[0035] После приема сообщения запроса вызова компонент сервера извлекает идентификатор объекта из сообщения запроса вызова и вызывает метод поиска ссылки («retrieveref») его объекта таблицы ID, передавая идентификатор объекта, чтобы найти ссылку на удаленный объект создания. Затем компонент сервера вызывает метод извлечения («extract») объекта запроса, чтобы извлечь любые входные параметры («inparam»). Компонент сервера затем извлекает из объекта запроса идентификатор метода у метода createX. Компонент сервера затем использует ссылку на удаленный объект создания и идентификатор метода createX, чтобы вызывать метод createX удаленного объекта создания, передавая входные параметры. Метод createX создает экземпляр удаленного объекта 124 («X2 object») класса X и возвращает выходной параметр, который является ссылкой на удаленный объект 124. Несмотря на то, что не проиллюстрировано посредством псевдокода, компонент сервера также вызывает метод добавления записи объекта 123 таблицы ID, чтобы добавить в свою таблицу ID запись, которая привязывает идентификатор объекта («2») для удаленного объекта 124 к ссылке для удаленного объекта 124 («X2») и добавляет в объект ответа («res») идентификатор объекта («res.ID») и идентификатор метода createX («res.method»). Затем компонент сервера вызывает метод хранения («store»), чтобы сохранить любые выходные параметры. Компонент сервера затем отправляет клиенту сообщение ответа вызова на основе объекта ответа.

[0036] После приема сообщения ответа вызова компонент клиента создает экземпляр объекта ответа на основе сообщения ответа вызова. Компонент клиента затем создает экземпляр прокси 114 («X2 proxy») и вызывает метод добавления записи объекта 113 таблицы ID, чтобы добавить в свою таблицу ID привязку идентификатора объекта («2») для прокси 114 к ссылке для прокси 114 («X2»). Если вызов метода createX был синхронным, тогда метод createX возвращает ссылку на прокси 114.

[0037] После того, как созданы экземпляры удаленного объекта 124 и его соответствующего прокси 114, приложение затем вызывает метод прокси 114, передавая указание входного параметра («in»). Вызванный метод может вызывать формирование компонентом клиента объекта запроса, который включает в себя идентификатор объекта прокси 114 («2»), идентификатор метода и входной параметр, отправку серверу сообщения запроса вызова на основе объекта запроса. После приема сообщения ответа запроса компонент сервера находит ссылку для удаленного объекта 124 в объекте таблицы ID и вызывает идентифицированный метод удаленного объекта 124, передавая входной параметр. Когда метод осуществляет возврат, компонент сервера формирует объект ответа, который включает в себя идентификатор объекта удаленного объекта 124 («2»), идентификатор метода и любые выходные параметры. Компонент сервера затем отправляет клиенту сообщение ответа вызова на основе объекта ответа. После приема сообщения ответа вызова компонент клиента извлекает выходные параметры и сигнализирует о том, что метод осуществил возврат, чтобы повлиять на обработку синхронного или асинхронного вызова.

[0038] Затем приложение может вызывать метод createX и метод createY прокси создания, чтобы осуществить создание удаленного объекта 125 («X3 object») и удаленного объекта 126 («Y4 object») на сервере и соответствующего прокси 115 («X3 proxy») и соответствующего прокси 116 («Y4 proxy») на клиенте. Затем приложение может вызывать методы удаленного объекта 125 и удаленного объекта 126 посредством вызова соответствующих методов прокси 115 и прокси 116.

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

[0040] Система OORPC может быть описана в общем контексте исполняемых компьютером инструкций, таких как программные модули или компоненты, исполняемых одним или более компьютерами, процессорами или другими устройствами. В целом, программные модули или компоненты включают в себя подпрограммы, программы, объекты, структуры данных и т.д., которые выполняют конкретные задачи или реализуют конкретные типы данных. Как правило, функциональные возможности программных модулей могут быть объединены или распределены как требуется в различных вариантах осуществления. Аспекты системы OORPC могут быть реализованы в аппаратном обеспечении, используя, например, проблемно-ориентированную интегральную микросхему (ASIC).

[0041] Фигура 2 является блок-схемой, которая иллюстрирует обработку метода прокси, который синхронно вызывается в некоторых вариантах осуществления. Методу 200, который автоматически формируется генератором кода системы OORPC, передаются один или более входных параметров, и он возвращает один или более выходных параметров. Метод отправляет серверу сообщение запроса вызова и принимает сообщение ответа вызова. На этапе 202 метод вызывает метод поиска идентификатора объекта таблицы ID, передавая ссылку на прокси («this»), чтобы найти идентификатор объекта прокси. Метод сохраняет идентификатор объекта прокси в объекте запроса. На этапе 204 метод добавляет идентификатор метода в объект запроса. На этапе 206 метод вызывает метод хранения параметров объекта запроса, чтобы сохранить входные параметры. На этапе 208 метод отправляет серверу сообщение запроса вызова, которое основано на объекте запроса. На этапе 210 метод принимает от сервера сообщение ответа вызова и формирует объект ответа. На этапе 212 метод вызывает метод извлечения параметров объекта ответа, чтобы извлечь выходные параметры. Затем метод завершается. В некоторых вариантах осуществления метод может вызывать компонент клиента, чтобы выполнять обработку этапов 202-212.

[0042] Фигура 3 является блок-схемой, которая иллюстрирует обработку компонента приема запроса компонента сервера в некоторых вариантах осуществления. Компонент 300 приема запроса вызывается, когда сообщение запроса вызова принимается от клиента и передается объект запроса, который основан на сообщении запроса вызова. Компонент вызывает метод удаленного объекта и отправляет клиенту сообщение ответа вызова. На этапе 302 компонент извлекает идентификатор объекта удаленного объекта из объекта запроса и вызывает метод поиска ссылки объекта таблицы ID, передавая идентификатор объекта, и принимает ссылку на удаленный объект. На этапе 304 компонент извлекает идентификатор метода из объекта запроса. На этапе 306 компонент вызывает метод извлечения параметров объекта запроса, чтобы извлечь входные параметры. На этапе 308 компонент вызывает метод идентификатора удаленного объекта, передавая входные параметры и принимая любые выходные параметры после возврата. На этапе 310 компонент формирует объект ответа, который включает в себя идентификатор объекта, идентификатор метода и выходные параметры. На этапе 312 компонент отправляет клиенту сообщение ответа вызова, которое основано на объекте ответа, и затем завершает обработку.

[0043] Фигура 4 является блок-схемой, которая иллюстрирует обработку метода извлечения параметров класса объекта ответа для объекта ответа компонента клиента в некоторых вариантах осуществления. Метод 400 извлечения параметров вызывается компонентом клиента, чтобы извлекать выходные параметры, которые возвращаются вызванным методом. На этапе 402 метод выбирает следующий выходной параметр, начиная с первого. На этапе 404 принятия решения, если все выходные параметры уже выбраны, тогда метод завершается, иначе метод продолжается на этапе 406. На этапе 406 принятия решения, если выбранным выходным параметром является идентификатор удаленного объекта, тогда метод продолжается на этапе 410, иначе метод продолжается на этапе 408. На этапе 408 компонент сохраняет выбранный выходной параметр в качестве выходного параметра и затем возвращается к этапу 402, чтобы выбрать следующий выходной параметр. На этапе 410 метод вызывает метод поиска ссылки объекта таблицы ID, чтобы найти ссылку на удаленный объект, идентифицированный в объекте ответа. На этапе 412 принятия решения, если ссылка является пустым указателем, тогда не был создан экземпляр прокси для удаленного объекта и метод продолжается на этапе 414, иначе метод продолжается на этапе 422. На этапе 414 метод создает экземпляр прокси для класса удаленного объекта. Генератор кода для системы OORPC может идентифицировать класс удаленного объекта и в целом тип любого параметра, из сигнатуры вызванного метода. На этапе 416 и 418 метод создает запись для таблицы ID. На этапе 420 метод вызывает метод добавления записи объекта таблицы ID, чтобы сохранить запись, и затем продолжается на этапе 422. На этапе 422 компонент устанавливает выходной параметр в возвращенную ссылку и затем возвращается к этапу 402, чтобы выбрать следующий выходной параметр объекта ответа.

[0044] Фигура 5 является блок-схемой, которая иллюстрирует обработку метода хранения параметров класса объекта ответа для объекта ответа компонента сервера в некоторых вариантах осуществления. Методу 500 хранения параметров передаются выходные параметры, которые должны быть сохранены в объекте ответа. На этапе 502 метод выбирает следующий выходной параметр. На этапе 504 принятия решения, если все выходные параметры уже выбраны, тогда метод завершается, иначе метод продолжается на этапе 506. На этапе 506 принятия решения, если выходным параметром является ссылка на объект, тогда компонент продолжается на этапе 508, иначе компонент продолжается на этапе 510. На этапе 508 компонент вызывает метод поиска ID объекта таблицы ID, чтобы найти идентификатор объекта, соответствующий ссылке, и устанавливает выходной параметр в ссылку. На этапе 510 компонент сохраняет выходной параметр в объекте ответа и затем возвращается к этапу 502, чтобы выбрать следующий выходной параметр. Несмотря на то, что не проиллюстрировано объект запроса также имеет метод извлечения параметров и метод хранения параметров, которые функционируют аналогично тем, что у объекта ответа.

[0045] Фигуры 6-9 являются блок-схемами, иллюстрирующими методы класса объекта таблицы ID в некоторых вариантах осуществления. Фигура 6 является блок-схемой, иллюстрирующей обработку метода поиска ID класса объекта таблицы ID в некоторых вариантах осуществления. Методу 600 поиска ID передается ссылка на объект, и он возвращает идентификатор объекта, соответствующий той ссылке. На этапе 602 метод выбирает следующую запись таблицы ID. На этапе 604 принятия решения, если все записи уже выбраны, тогда метод возвращает значение пустого указателя, чтобы указать то, что запись для ссылки отсутствует в таблице ID, иначе метод продолжается на этапе 606. На этапе 606 принятия решения, если ссылка в выбранной записи совпадает с переданной ссылкой, тогда метод возвращает указание идентификатора объекта этой записи, иначе метод возвращается к этапу 602, чтобы выбрать следующую запись таблицы ID.

[0046] Фигура 7 является блок-схемой, которая иллюстрирует обработку метода поиска ссылки объекта таблицы ID в некоторых вариантах осуществления. Методу 700 поиска ссылки передается идентификатор объекта, и он возвращает ссылку, соответствующую тому идентификатору объекта. На этапе 702 метод находит следующую запись таблицы ID. На этапе 704 принятия решения, если все записи уже выбраны, тогда метод возвращает значение пустого указателя, чтобы указать, что запись для идентификатора объекта отсутствует в таблице ID, иначе метод продолжается на этапе 706. На этапе 706 принятия решения, если идентификатор объекта выбранной записи совпадает с переданным идентификатором объекта, тогда метод возвращает ссылку выбранного объекта, иначе метод возвращается к этапу 702, чтобы выбрать следующую запись таблицы ID.

[0047] Фигура 8 является блок-схемой, которая иллюстрирует обработку метода добавления записи объекта таблицы ID, которому передается ссылка в некоторых вариантах осуществления. Методу 800 добавления записи передается ссылка на объект (т.е., прокси или удаленный объект), и он добавляет запись в таблицу ID для той ссылки, если таблица ID еще не содержит запись для той ссылки. На этапе 802 метод вызывает метод поиска ID данного объект таблицы ID, передавая ссылку, чтобы найти идентификатор объекта, если таблица ID содержит запись, соответствующую ссылке. На этапе 804 принятия решения, если возвращенный идентификатор объекта является пустым указателем, тогда таблица ID не содержит соответствующую запись и метод продолжается на этапе 806, иначе метод возвращает идентификатор объекта. На этапе 806 метод устанавливает идентификатор объекта в следующее поле идентификатора объекта у объекта таблицы ID и дает приращение следующему полю идентификатора объекта. На этапах 808-810 метод инициализирует запись для ссылки. На этапе 812 метод добавляет запись в таблицу ID и затем возвращает указание идентификатора объекта.

[0048] Фигура 9 является блок-схемой, которая иллюстрирует обработку метода добавления записи объекта таблицы ID, которому передается запись в некоторых вариантах осуществления. Методу 900 добавления записи передается запись, которая должна быть добавлена в таблицу ID, если запись еще не присутствует в таблице ID. На этапе 902 метод вызывает метод поиска ID данного объекта таблицы ID, передавая ссылку записи. На этапе 904 принятия решения, если запись является пустым указателем, тогда таблица ID не содержит эту запись и метод продолжается на этапе 906, иначе метод осуществляет возврат. На этапе 906 метод добавляет запись в таблицу ID и затем осуществляет возврат.

[0049] В некоторых вариантах осуществления система OORPC позволяет как клиенту, так и серверу размещать удаленные объекты, доступ к которым осуществляют удаленно другой стороной. Клиент и сервер таким образом могут рассматриваться в качестве одноранговых узлов в том смысле, что на обоих размещены удаленные объекты. Например, если документ обрабатывается в среде сотрудничества несколькими клиентами, то каждый клиент может регистрировать объект с сервером, чтобы принимать уведомления о событии касательно изменений в документе. В таком случае, клиент может вызывать метод регистрации прокси-документа, передавая объект прослушивания события, экземпляр которого создается клиентом. Клиент может сохранять таблицу ID прокси для привязки идентификаторов объекта к ссылкам на прокси для объектов, размещенных удаленно сервером, и таблицу ID объекта, которая привязкам идентификаторы объекта к ссылкам на объекты, размещенные локально клиентом. Аналогичным образом сервер может сохранять таблицу ID прокси для привязки идентификаторов объекта к ссылкам на прокси для объектов, которые размещены удаленно на клиенте, и таблицу ID объекта, которая привязывает идентификаторы объекта к ссылкам на объекты, которые размещены локально на сервере. Метод регистрации прокси-документа может добавлять запись для объекта прослушивания события в таблицу ID объекта и включать идентификатор объекта записи в качестве входного параметра в сообщение запроса вызова для метода регистрации. Когда сервер принимает сообщение запроса вызова, компонент сервера может осуществлять поиск как по таблице ID объекта, так и по таблице ID прокси записи с совпадающим идентификатором объекта. Если такая запись найдена, компонент сервера замещает идентификатор объекта ссылкой записи в качестве входного параметра для метода регистрации. Если такая запись не найдена, компонент сервера создает экземпляр прокси-прослушивания события для объекта прослушивания события и добавляет запись в таблицу ID прокси, которая привязывает идентификатор объекта к ссылке на прокси-объекта прослушивания ссылки. Затем компонент сервера вызывает метод регистрации удаленного объекта документа, передавая ссылку на прокси-прослушивания. Когда компонент сервера отправляет событие приложению, код сервера вызывает метод события прокси-прослушивания, который отправляет клиенту сообщение запроса вызова. Когда клиент принимает сообщение запроса вызова, компонент клиента обрабатывает сообщение запроса вызова во многом также, как компонент сервера у сервера обрабатывает сообщения запроса вызова. Таким образом, как клиент, так и сервер могут вызывать методы удаленных объектов, которые размещены удаленно на другой стороне.

[0050] В некоторых вариантах осуществления метод объекта удаленного объекта может иметь входной параметр и/или выходной параметр, который передается посредством значения. Чтобы передать входной параметр посредством значения, метод прокси у прокси, соответствующего удаленному объекту, находит значение для входного параметра и добавляет найденное значение в сообщение запроса вызова. Если входной параметр сам является удаленным объектом, который размещен на сервере, тогда метод прокси может отправлять сообщение запроса вызова серверу, чтобы находить значение. Аналогичным образом, при возврате выходного параметра посредством значения, метод объекта находит значение выходного параметра и добавляет найденное значение в сообщение ответа вызова. В некоторых вариантах осуществления входной параметр или выходной параметр могут быть структурой данных, содержащей несколько объектов. Чтобы передать входной параметр, который является такой структурой данных, метод прокси находит идентификатор объекта каждого объекта в структуре данных и добавляет каждый идентификатор объекта в сообщение запроса вызова. Например, если структура данных является массивом, метод прокси для каждого элемента массива выбирает элемент, находит идентификатор объекта выбранного элемента и добавляет найденный идентификатор объекта в сообщение запроса вызова. Чтобы передать выходной параметр, который является массивом, метод объекта обрабатывает элементы массива аналогичным образом. Структура данных входного параметра или выходного параметра может содержать объект, размещенный на сервере, и объект, размещенный на клиенте. При обработке такого входного параметра метод прокси добавляет идентификатор объекта каждого объекта в сообщение запроса вызова. После приема сообщения запроса вызова компонент сервера находит ссылки на объекты либо по таблице идентификатора объекта, либо по таблице идентификатора прокси и вызывает метод объекта, передавая найденные ссылки. Компонент сервера может создавать экземпляр соответствующего объекта или прокси, если экземпляр еще не создан.

[0051] Фигура 10 является структурной схемой, которая иллюстрирует реализацию системы OORPC, которая поддерживает размещение в одноранговым узле удаленных объектов в некоторых вариантах осуществления. Клиент 1010 включает в себя объект 1011 таблицы ID прокси и объект 1015 таблицы ID объекта. Объект 1011 таблицы ID прокси включает в себя таблицу ID, которая содержит записи для прокси 1012, а объект 1015 таблицы ID объекта включает в себя таблицу ID, которая содержит записи для удаленных объектов 1016. Сервер 1020 включает в себя объект 1021 таблицы ID объекта и объект 1025 таблицы ID прокси. Объект 1021 таблицы ID объекта включает в себя таблицу ID, которая содержит записи для каждого объекта 1022, а объект 1025 таблицы ID прокси включает в себя таблицу ID, которая содержит запись для каждого прокси 1026.

[0052] Фигура 11 является структурной схемой, которая иллюстрирует структуры данных, которые поддерживают синхронизацию значений свойств посредством системы OORPC в некоторых вариантах осуществления. Клиент 1110 включает в себя объект 1111 таблицы ID c таблицей ID, которая включает в себя записи для прокси 1112 и 1113 для удаленных объектов класса X удаленного объекта, и которая включает в себя записи для прокси 1114 для удаленного объекта класса Y удаленного объекта. Каждый прокси включает в себя статические данные-член для ссылки на объект хранения для своего класса удаленного объекта. Прокси 1112 и 1113 включают в себя ссылку на объект 1115 хранения для класса X удаленного объекта, и прокси 1114 включает в себя ссылку на объект 1116 хранения для класса Y удаленного объекта. Объект хранения для класса удаленного объекта может включать в себя метод для каждого получающего метода класса удаленного объекта, который хранит значение для свойства локально в прокси. Сервер 1120 включает в себя объект 1121 таблицы ID с таблицей ID, которая включает в себя записи для удаленных объектов 1122 и 1123 класса X удаленного объекта и включает в себя запись для объекта 1124 класса Y удаленного объекта. Сервер также включает в себя объект 1125 таблицы свойств с таблицей свойств, которая включает в себя запись для каждого свойства каждого удаленного объекта. Каждая запись включает в себя идентификатор объекта удаленного объекта, последнее найденное значение для каждого свойства удаленного объекта и ссылку на таблицу метода получения для класса удаленного объекта у удаленного объекта. В некоторых вариантах осуществления каждая запись может содержать ссылку на структуру данных, которая хранит последние найденные значения для удаленного объекта. Также, таблица ID и таблица свойств могут быть объединены в единую таблицу. Как иллюстрируется первая запись таблицы свойств соответствует удаленному объекту 1122 и включает в себя указатель на таблицу 1126 метода получения для класса X удаленного объекта. Таблица 1126 метода получения включает в себя запись для каждого получающего метода 1128 и 1129 класса X удаленного объекта. Таблица 1127 метода получения включает в себя запись для каждого получающего метода 1130 и 1131 класса Y удаленного объекта. Записи указывают на код, который вызывает соответствующий получающий метод удаленного объекта, чтобы найти значение свойства.

[0053] Перед отправкой сообщения ответа вызова, компонент сервера может выбирать каждую запись таблицы свойства и вызывать получающие методы удаленного объекта каждой записи, чтобы находить значение каждого свойства. Если значение свойства, которое возвращается получающим методом для объекта, отличается от значения для того свойства, которое хранится в таблице свойства, то компонент сервера добавляет обновление свойства в сообщение ответа вызова. Обновление свойства включает в себя идентификатор объекта, идентификатор приоритета и новое значение. Когда клиент принимает сообщение ответа вызова, компонент клиента обрабатывает каждое обновление свойства. Для каждого обновления свойства компонент клиента находит ссылку на прокси, соответствующий идентификатору объекта обновления свойства. Компонент клиента находит ссылку на объект хранения в прокси и вызывает соответствующий метод хранения для того свойства объекта хранения, передавая указание ссылки. Затем метод хранения сохраняет значение свойства в прокси. В некоторых вариантах осуществления каждое обновление свойства может содержать значение для всех измененных свойств удаленного объекта. Т.е. сообщение ответа вызова содержит только одно обновление свойства для удаленного объекта вместо отдельного обновления свойства для каждого измененного свойства удаленного объекта.

[0054] Фигура 12 является блок-схемой, которая иллюстрирует обработку компонента получения значений свойства компонента сервера в некоторых вариантах осуществления. Компонент 1200 получения значений свойства вызывается, чтобы добавлять обновление свойства в сообщение ответа вызова для каждого свойства каждого удаленного объекта, значение которого изменилось. На этапе 1202 компонент выбирает следующую запись из таблицы свойств. На этапе 1204 принятия решения, если все записи уже выбраны, тогда компонент завершает обработку, иначе компонент продолжает на этапе 1206. На этапе 1206 компонент вызывает метод поиска ссылки объекта таблицы ID, чтобы найти ссылку, соответствующую идентификатору объекта выбранной записи. На этапах 1208-1218 компонент зацикливает обработку каждого свойства удаленного объекта, на который ссылаются. На этапе 1208 компонент выбирает следующий получающий метод из таблицы метода получения, на который ссылается выбранная запись. На этапе 1210 принятия решения, если все получающие методы уже выбраны, тогда компонент возвращается к блоку 1202, чтобы выбрать следующую запись в таблице свойств, иначе компонент продолжает на этапе 1212. На этапе 1212 компонент вызывает выбранный получающий метод удаленного объекта, на который ссылаются. На этапе 1214 принятия решения, если текущее значение свойства является точно таким же, как значение в выбранной записи для свойства, тогда компонент возвращается к блоку 1208, чтобы выбрать следующий выбирающий метод, иначе компонент продолжает на этапе 1216. На этапе 1216 компонент устанавливает значение в записи для свойства в текущее значение. На этапе 1218 компонент добавляет обновление свойства с идентификатором объекта, идентификатором свойства и текущим значением свойства в сообщение ответа вызова и затем возвращается на этап 1208, чтобы выбрать следующий получающий метод.

[0055] Фигура 13 является блок-схемой, которая иллюстрирует обработку компонента хранения значений свойства компонента клиента в некоторых вариантах осуществления. Компонент 1300 хранения значений свойства вызывается, когда принимается сообщение ответа вызова, которое включает в себя обновления свойства, и он обновляет локально хранящиеся значения для свойств. На этапе 1302 компонент выбирает следующее обновление свойства сообщения ответа вызова. На этапе 1304 принятия решения, если все обновления свойства уже выбраны, тогда компонент завершает обработку, иначе компонент продолжает на этапе 1306. На этапе 1306 компонент вызывает метод поиска ссылки объекта таблицы ID, передавая идентификатор объекта выбранной записи, и принимает ссылку на соответствующий прокси. На этапе 1308 компонент вызывает метод хранения объекта хранения, на который ссылаются статические данные-член прокси, передавая значение записи. Затем компонент возвращается к блоку 1302, чтобы выбрать следующую запись обновления свойства сообщения ответа вызова. Объект хранения может иметь отдельный метод хранения, сформированный для обработки каждого свойства. В качестве альтернативы объект хранения может иметь один метод хранения, который осуществляет доступ к таблице с записью для каждого свойства с информацией, такой как тип объекта и имя свойства.

[0056] Фигура 14 является блок-схемой, которая иллюстрирует генератор кода системы OORPC для автоматического формирования кода для прокси-классов в некоторых вариантах осуществления. Компоненту 1400 кода прокси передается интерфейс для каждого класса объектов, которые размещены на сервере, и он формирует прокси-классы (например, JavaScript). На этапе 1402 компонент выбирает следующий интерфейс. На этапе 1404 принятия решения, если все интерфейсы уже выбраны, тогда компонент завершает обработку, иначе компонент продолжает на этапе 1406. На этапе 1406 компонент формирует первоначальный код для прокси-класса, который может включать в себя шаблон класса, который включает в себя имя класса, начальный и конечный символы класса (например, круглые скобки) и т.д. На этапах 1408-1412 компонент зацикливает обработку каждого метода интерфейса, который не является получающим методом. На этапе 1408 компонент выбирает следующий метод. На этапе 1410 принятия решения, если все методы уже выбраны, тогда компонент продолжает на этапе 1414, иначе компонент продолжает на этапе 1412. На этапе 1412 компонент формирует код для выбранного метода прокси-класса и затем возвращается на этап 1408, чтобы выбрать следующий метод. На этапе 1414 компонент вызывает компонент обработки свойств прокси генератора кода, передавая указание выбранного интерфейса, чтобы сформировать код для класса хранения для прокси-класса. Затем компонент возвращается к этапу 1402, чтобы выбрать следующий интерфейс.

[0057] Фигура 15 является блок-схемой, которая иллюстрирует обработку компонента обработки свойств прокси генератора кода в некоторых вариантах осуществления. Компонент 1500 обработки свойств прокси вызывается, чтобы сформировать класс хранения для прокси-класса и добавить статические данные-член в прокси-класс для хранения ссылки на объекте хранения для прокси-класса. На этапе 1502 компонент формирует первоначальный код для класса хранения. На этапе 1504 компонент добавляет в прокси-класс статические данные-член для ссылки на объект хранения. На этапе 1506 компонент выбирает следующее свойство интерфейса. На этапе 1508 принятия решения, если все свойства интерфейса уже выбраны, тогда компонент завершает обработку, иначе компонент продолжает на этапе 1510. На этапе 1510 компонент формирует код для устанавливающего метода прокси-класса для выбранного свойства, который отправляет сообщение запроса вызова серверу. На этапе 1512 компонент формирует код для получающего метода прокси-класса для выбранного свойства, который находит локальное значение свойства. На этапе 1514 компонент формирует коды для метода хранения класса хранения для хранения в прокси значения выбранного свойства, которое принимается в сообщении ответа вызова, и затем возвращается к этапу 1506, чтобы выбрать следующее свойство интерфейса.

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

[0059] Фигура 16 и 17 являются блок-схемами, которые иллюстрируют отсрочку запросов вызова в некоторых вариантах осуществления. Фигура 16 является блок-схемой, которая иллюстрирует обработку компонента отправки запроса компонента клиента в некоторых вариантах осуществления. Компонент 1600 отправки запроса вызывается, передавая запрос вызова (например, через запрос объекта), чтобы вызывать метод удаленного объекта. Компонент отправляет серверу сообщение запроса вызова с любыми стоящими в очереди запросами вызова, если вызов метода не допускает отсрочку. На этапе 1602 компонент добавляет запрос вызова в очередь запросов. На этапе 1604 принятия решения, если вызов метода допускает отсрочку, тогда компонент завершает обработку, иначе компонент продолжает на этапе 1606. На этапе 1606 компонент добавляет запросы вызова из очереди запросов вызова в сообщение запроса вызова. На этапе 1608 компонент отправляет серверу сообщение запроса вызова. На этапе 1610 компонент освобождает очередь запросов и затем завершает обработку.

[0060] Фигура 17 является блок-схемой, которая иллюстрирует обработку компонента приема запроса компонента сервера в некоторых вариантах осуществления. Компонент 1700 приема запроса вызывается, когда компонент сервера принимает сообщение запроса вызова. На этапе 1702 компонент выбирает следующий запрос вызова сообщения запроса вызова. На этапе 1704 принятия решения, если все запросы вызова уже выбраны, тогда компонент завершает обработку, иначе компонент продолжает на этапе 1706. На этапе 1706 компонент обрабатывает выбранный запрос вызова посредством вызова метода удаленного объекта, идентифицированного запросом вызова. Затем компонент возвращается к этапу 1702, чтобы выбрать следующий запрос вызова.

[0061] Нижеследующие абзацы описывают различные варианты осуществления аспектов системы OORPC. Реализация системы OORPC может использовать любую комбинацию вариантов осуществления. Обработка, описанная ниже, может быть выполнена посредством вычислительного устройства с процессором, который исполняет исполняемые компьютером инструкции, хранящиеся на машиночитаемом запоминающем носителе информации, который реализует систему OORPC.

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

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

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

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

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

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

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

[0069] В некоторых вариантах осуществления предоставляется способ, выполняемый клиентом для отправки запросов вызова приложения удаленным объектам сервера. Способ принимает запросы вывоза. Каждый запрос вызова является от прокси у прокси-класса приложения, соответствующего удаленному объекту класса удаленного объекта. Для каждого принятого запроса вызова, когда запрос вызова допускает отсрочку, способ сохраняет запрос вызова. Когда запрос вызова не допускает отсрочку, способ отправляет серверу сообщение запроса вызова, которое включает в себя каждый сохраненный запрос вызова, который ранее не был отправлен, и принятый запрос вызова. Способ принимает от сервера сообщения ответа вызова. Каждое сообщение ответа вызова является в ответ на сообщение запроса вызова, которое включает в себя один или более запросы вызова. По меньшей мере одно сообщение ответа вызова включает в себя несколько ответов вызова. Для каждого ответа вызова принятого сообщения ответа вызова, когда ответ вызова включает в себя выходной параметр, способ извлекает выходной параметр из ответа вызова. Способ предоставляет приложению указание того, что был принят ответ вызова и любой извлеченный выходной параметр. В некоторых вариантах осуществления сообщение запроса вызова указывает очередность, в которой были приняты запросы вызова. В некоторых вариантах осуществления ответы вызова сообщения ответа вызова обрабатываются в очередности, в которой были приняты соответствующие запросы вызова. В некоторых вариантах осуществления запросы вызова являются асинхронными запросами вызова. В некоторых вариантах осуществления, когда запрос вызова хранился в течение назначенного количества времени, способ отправляет сообщение запроса вызова, которое включает в себя запрос вызова. В некоторых вариантах осуществления в ответ на прием от приложения запроса чтобы отправить неотправленный запрос вызова, способ дополнительно отправляет сообщение запроса вызова, которое включает в себя запрос вызова. В некоторых вариантах осуществления запросы вызова принимаются для удаленных объектов, которые размещены на разных серверах, и при этом сообщение запроса вызова, которое отправляется серверу, включает в себя только запросы вызова для удаленных объектов, которые размещены на том сервера. В некоторых вариантах осуществления приложение исполняется под управлением браузера.

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

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

[0072] Несмотря на то, что изобретение было описано языком, особым для структурных признаков и/или действий, следует понимать, что объем изобретения, определяемый прилагаемой формулой изобретения, не обязательно ограничен особыми признаками или действиями, описанными выше. Наоборот особые признаки и действия, описанные выше, раскрываются в качестве примерных форм реализации формулы изобретения. Например, несмотря на то, что система OORPC описывается главным образом в контексте веб-браузера, который исполняет приложение, OORPC может быть использована в других контекстах. Например, система управления взаимодействием с клиентами («CRM») может обеспечивать разработку приложений, чтобы модифицировать в соответствии с требованиями заказчика систему CRM. В таком случае компонент стороны клиента системы CRM исполняет приложения, которые осуществляют доступ к объектам, размещенным на сервере, который имеет компонент стороны сервера системы CRM. Веб-браузеры, система CRM и прочие программы, которые исполняют такие приложения, могут упоминаться как программа с машиной исполнения приложения. Соответственно, изобретение не ограничено, кроме как прилагаемой формулой изобретения.

1. Способ, выполняемый клиентом для отправки запросов вызова со стороны приложения в удаленные объекты сервера, при этом способ содержит этапы, на которых:

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

для каждого принятого запроса вызова определяют, допускает ли запрос вызова отсрочку;

когда запрос вызова допускает отсрочку, сохраняют запрос вызова, и

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

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

для каждого ответа вызова из принятого сообщения ответа вызова,

когда ответ вызова включает в себя выходной параметр, извлекают этот выходной параметр из ответа вызова и

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

2. Способ по п.1, в котором запросы вызова представляют собой асинхронные запросы вызова.

3. Способ по п.1, в котором, когда запрос вызова хранился более назначенного количества времени, отправляют сообщение запроса вызова, которое включает в себя этот запрос вызова.

4. Способ по п.1, дополнительно содержащий этап, на котором в ответ на прием от приложения запроса отправить неотправленный запрос вызова, отправляют сообщение запроса вызова, которое включает в себя этот запрос вызова.

5. Способ по п.1, в котором запросы вызова принимаются для удаленных объектов, размещенных на разных серверах, причем сообщение запроса вызова, которое отправлено на сервер, включает в себя только запросы вызова для удаленных объектов, размещенных на этом сервере.

6. Способ по п.1, в котором приложение исполняется под управлением браузера.

7. Способ по п.1, в котором запросы вызова обрабатываются в очередности, задаваемой сообщением запроса вызова.

8. Способ, выполняемый сервером для обработки запросов вызова со стороны приложения, при этом способ содержит этапы, на которых:

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

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

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

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

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

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

9. Способ по п.8, в котором запросы вызова, соответствующие ответам вызова, являются идентифицируемыми из ответов вызова.

10. Способ по п.8, в котором запросы вызова представляют собой асинхронные запросы вызова.

11. Способ по п.8, в котором сообщение запроса вызова включает в себя запрос вызова, который хранился более назначенного количества времени.

12. Способ по п.8, в котором сообщение запроса вызова посылается с клиента в качестве реакции на прием от приложения запроса оправить неотправленный запрос вызова, при этом сообщение запроса вызова включает в себя этот неотправленный запрос вызова.

13. Способ по п.8, в котором сообщение запроса вызова включает в себя только запросы вызова для удаленных объектов, размещенных на упомянутом сервере.

14. Способ по п.8, в котором приложение исполняется под управлением браузера.

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

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

для каждого принятого запроса вызова определяют, допускает ли запрос вызова отсрочку;

когда запрос вызова допускает отсрочку, сохраняют запрос вызова, и

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

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

для каждого ответа вызова из принятого сообщения ответа вызова,

когда ответ вызова включает в себя выходной параметр, извлекают этот выходной параметр из ответа вызова и

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

16. Машиночитаемое запоминающее устройство по п.15, при этом запросы вызова представляют собой асинхронные запросы вызова.

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

18. Машиночитаемое запоминающее устройство по п.15, при этом способ дополнительно содержит этап, на котором: в качестве реакции на прием от приложения запроса отправить неотправленный запрос вызова, отправляют сообщение запроса вызова, которое включает в себя этот запрос вызова.

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