АВТОМАТИЗИРОВАННОЕ ПРЕОБРАЗОВАНИЕ ОБЪЕКТА ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ И ГЕНЕРАЦИЯ КОДА Российский патент 2016 года по МПК G06F15/16 

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

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

Одной формой архитектуры клиент-сервер является многозвенная архитектура, часто называемая n-звенной архитектурой. N-звенная архитектура является архитектурой клиент-сервер, в которой некоторые аспекты прикладной программы разделены на несколько звеньев. Например, приложение, которое использует промежуточное программное обеспечение для обслуживания запросов данных между пользователем и базой данных, использует многозвенную архитектуру. N-звенная архитектура приложения обеспечивает для разработчиков модель для создания гибкого и многократно используемого приложения. Посредством разбиения приложения на несколько звеньев разработчики должны лишь изменить или добавить конкретное звено (или слой) с исключением тем самым необходимости переписывать все приложение.

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

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

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

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

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

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

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

Фиг. 1A - изображение обычной архитектуры классического приложения для настольной системы.

Фиг. 1B - изображение обычной 2-звенной архитектуры приложения.

Фиг. 1C - изображение обычной 3-звенной архитектуры приложения.

Фиг. 2 - блок-схема расширенной n-звенной архитектуры клиент-сервер, содержащей несколько клиентов и адаптеры клиентов в соответствии с одним вариантом осуществления.

Фиг. 3 - блок-схема расширенной n-звенной архитектуры клиент-сервер, содержащей единственного клиента и адаптер клиента в соответствии с одним вариантом осуществления.

Фиг. 4 - блок-схема расширенной n-звенной архитектуры клиент-сервер, содержащей объект, независимый от графического интерфейса пользователя (GUI), (GUI-независимый объект) для клиента и адаптера клиента в соответствии с одним вариантом осуществления.

Фиг. 5 - первая логическая блок-схема последовательности операций в расширенной n-звенной архитектуре клиент-сервер в соответствии с одним вариантом осуществления.

Фиг. 6A - логическая схема GUI-независимого объекта в соответствии с одним вариантом осуществления.

Фиг. 6B - вторая логическая схема конкретного GUI-независимого объекта в соответствии с одним вариантом осуществления.

Фиг. 7 - вторая логическая блок-схема последовательности операций расширенной n-звенной архитектуры клиент-сервер в соответствии с одним вариантом осуществления.

Фиг. 8A - блок-схема расширенной n-звенной архитектуры клиент-сервер для обработки шаблона, характеризующего компоновку объекта интерфейса GUI в соответствии с одним вариантом осуществления.

Фиг. 8B - первое представление интерфейса пользователя, сформированное на основании характерной компоновки объекта интерфейса GUI в соответствии с одним вариантом осуществления.

Фиг. 8C - первое представление интерфейса пользователя, сформированное на основании характерной компоновки объекта интерфейса GUI в соответствии с одним вариантом осуществления.

Фиг. 9 - третья логическая блок-схема последовательности операций системы обработки шаблона в соответствии с одним вариантом осуществления.

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

Фиг. 11 - изображение варианта осуществления архитектуры системы связи, пригодной для расширенной n-звенной архитектуры клиент-сервер в соответствии с одним вариантом осуществления.

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

Различные варианты осуществления относятся, в общем, к архитектуре клиент-сервер, пригодной для исполнения разнотипных коммерческих производственных прикладных программ. Некоторые варианты осуществления относятся, в частности, к расширенной n-звенной архитектуре клиент-сервер, где n является переменной, являющейся любым положительным целым числом. Расширенная n-звенная архитектура может содержать несколько звеньев (или слоев) прикладной программы, в том числе, по меньшей мере, одно звено представления. В одном варианте осуществления, например, расширенная n-звенная архитектура может быть осуществлена в форме 3-звенной архитектуры, содержащей, по меньшей мере, одно звено представления, звено обработки приложением и звено управления данными. Звено представления, в общем, реализует логику интерфейса пользователя, например обработку операций ввода/вывода. Звено обработки приложением, в общем, реализует логику приложения или бизнес-логику, например, обработку данных в соответствии с набором правил приложения. Звено управления данными, в общем, осуществляет хранение данных и обращение к данным, например, установку схем данных, хранение данных, обработку запросов данных и т.д.

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

На фиг. 1A, 1B и 1C показаны три обычные архитектуры для разработки приложения с использованием технологий существующего уровня техники для выделения преимуществ различных вариантов осуществления расширенной n-звенной архитектуры клиент-сервер. На фиг. 1A показана обычная архитектура для настольной системы. На фиг. 1B показана обычная 2-звенная архитектура. На фиг. 1C показана обычная 2-звенная (или n-звенная) архитектура.

На фиг. 1A приведен пример архитектуры 100 для настольной системы, в которой все части (или прикладные слои) прикладной программы 112 осуществлены на клиентском компьютере 110 (например, настольном компьютере). Прикладная программа 112 может содержать различные прикладные слои, осуществляющие, например, логику интерфейса пользователя (UI), бизнес-логику и логику доступа к базе данных. Прикладная программа 112 может сохранять и выбирать данные приложения из базы данных 114, которая также осуществлена на клиентском компьютере 110.

На фиг. 1B приведен пример 2-звенной архитектуры 120, в которой база данных 114 удалена от клиентского компьютера 10. В 2-звенной архитектуре 120 прикладная программа 112 и составляющие ее прикладные слои по-прежнему находится на клиентском компьютере 110. Однако база данных 114 вынесена из клиентского компьютера 110 на сервер 116 базы данных. Прикладная программа 112, выполняемая в клиентском компьютере 110, посылает запросы данных посредством программных интерфейсов приложений (API) баз данных в сервер 116 базы данных, который связан с возможностью обмена данными с базой данных 114. Затем запрошенные данные посылаются обратно в прикладную программу 112, выполняемую на клиентском компьютере 110.

На фиг. 1C приведен пример 3-звенной архитектуры 130. В 3-звенной архитектуре 130 прикладная программа 112 может быть разделена на распределенные прикладные программы 112, 124, выполняемые на соответствующем клиентском компьютере 110 и сервере 122. Прикладная программа 112 может осуществлять логику приложения, содержащую логику интерфейса пользователя (UI). Прикладная программа 124 может осуществлять слой приложения, содержащий бизнес-логику и логику доступа к базе данных. Прикладная программа 112, выполняемая в клиентском компьютере 110, посылает данные в сервер 122, который выполняет прикладную программу 124. Затем прикладная программа 124 может выполнять бизнес-логику и посылать запросы данных в сервер 116 базы данных, который связан с возможностью обмена данными с базой данных 114. Затем, запрошенные данные и результаты выполненной бизнес-логики посылаются обратно в прикладную программу 112 и визуально представляются на клиентском компьютере 110. Следует отметить, что сервер 116 базы данных может быть совмещен с сервером 122 или быть составной частью сервера 122. Другими словами, аппаратная архитектура может быть такой, что один сервер 122 функционирует в виде как сервера приложений, так и сервера базы данных. Признак различия между 2-звенной и 3-звенной (или n-звенной) архитектурами заключается в том, что некоторые или многие из слоев приложения вынесены из клиентского компьютера 110 и распределены между одним или более другими серверами 116, 122.

N-звенная архитектура, например 3-звенная архитектура 130, может обеспечивать множество преимуществ по сравнению с 2-звенной архитектурой 120 при разработке и изменении прикладной программы. Например, одно звено можно изменять или добавлять без необходимости полного переписывания всей прикладной программы. Однако при осуществлении n-звенной архитектуры для веб-среды, в которой существует большое число клиентов, существуют трудности. Каждый клиент может использовать разные веб-технологии, в том числе разные веб-браузеры, веб-службы и веб-приложения. Кроме того, веб-технологии предназначены для работы с базовыми архитектурами аппаратного и программного обеспечения многих различных типов, в том числе множеством различных устройств, имеющих разные компоненты ввода/вывода (I/O), параметры формы, требования к электропитанию, возможности обработки данных, коммуникационные возможности, ресурсы памяти и т.д. По существу, осуществление заданного слоя приложения, например слоя представления, равномерно через упомянутые многочисленные разнородные устройства и архитектуры, без расширенной настройки слоя представления для соответствия индивидуальной конфигурации каждого клиента, может быть сложной проблемой. Кроме того, веб-версии прикладной программы могут быть не совместимыми с версиями прикладной программы, не предназначенными для веб-системы, что создает потребность в отдельных архитектурах программного обеспечения для каждой версии.

В различных вариантах осуществления расширенная n-звенная архитектура обеспечивает платформу, которая допускает миграцию 2-звенной архитектуры приложения клиент-сервер в 3-звенную архитектуру приложения, которая использует тонкого клиента для слоя представления прикладной программы. В одном варианте осуществления, например, каждое клиентское устройство может осуществлять тонкого клиента в форме веб-клиента. Обычно веб-клиент относится к приложению тонкого клиента, осуществленному с использованием веб-технологий, например, веб-браузера, работающего, например, в клиентском компьютере. Упомянутый термин может также относиться к подключаемым модулям и вспомогательным приложениям, которые расширяют браузер для поддержки пользовательских служб из сайта или сервера. Любые ссылки в настоящей заявке на веб-клиента могут также относиться к функциональным возможностям веб-браузера.

На фиг. 2 показана система 200 клиент-сервер. В одном варианте осуществления система 200 клиент-сервер может содержать расширенную n-звенную систему клиент-сервер. Расширенная n-звенная система клиент-сервер может разделять прикладную программу на несколько звеньев, в том числе, по меньшей мере, одно звено представления. Звено представления может быть осуществлено с использованием методов, предназначенных для поддержки разделения и оптимизации событий визуального представления на интерфейсе GUI и пользовательских событий в прикладной программе с использованием интерпретирующего модуля исполняющей среды. Данное решение допускает адаптацию приложения интерпретирующего модуля исполняющей среды из архитектуры на основе 2-звенной технологии клиент-сервер к 3-звенной среде выполнения программ под управлением главной программы, при уменьшении изменений, необходимых для приложения интерпретирующего модуля исполняющей среды.

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

В наглядном варианте осуществления, показанном на фиг. 2, система 200 клиент-сервер может содержать сервер 202 и несколько клиентов 204, 206. При осуществлении на разных аппаратных платформах сервер 202 и клиенты 204, 206 могут устанавливать связь между собой по сети 250. При осуществлении на одной аппаратной платформе сервер 202 и клиенты 204, 206 могут устанавливать связь между собой по шинам с подходящими технологиями и архитектурами. Хотя на фиг. 2 изображены только один сервер 202 и два клиента 204, 206 для ясности, можно представить, что система 200 клиент-сервер может осуществить любое число серверов и клиентов, необходимое для данного варианта осуществления. Варианты осуществления не ограничены в данном отношении.

В одном варианте осуществления сервер 202 может содержать электронное устройство, осуществляющее серверное приложение 210. Серверное приложение 210 может содержать серверное приложение любого типа, например коммерческое производственное приложение. Примеры коммерческих производственных приложений могут включать в себя, без ограничения, бухгалтерскую программу, приложение для планирования ресурсов предприятия (ERP), приложение для управления отношениями с клиентами (CRM), приложение для управления логистическими цепочками (SCM) и т.д. Упомянутые коммерческие производственные приложения иногда называют приложениями «среднего звена», так как данные приложения обычно исполняются серверами или массивами серверов в сетях коммерческих предприятий, а не в таких клиентских устройствах, как настольный компьютер. Конкретный пример может включать в себя Microsoft Dynamics GP, компании Microsoft Corporation, Redmond, шт. Вашингтон. Microsoft Dynamics GP является коммерческим бухгалтерским приложением. Другой конкретный пример коммерческого производственного приложения может содержать Microsoft Dynamics® AX, компании Microsoft Corporation, Redmond, шт. Вашингтон. Microsoft Dynamics AX является коммерческим приложением ERP (для планирования ресурсов предприятия). Однако варианты осуществления не ограничены приведенными примерами.

Когда сервер 202 выполняет код для серверного приложения 210, то сервер 202 формирует интерпретирующий модуль 212 исполняющей среды. Интерпретирующий модуль 212 исполняющей среды осуществляет несколько слоев приложения для серверного приложения 210, называемых в системе 200 клиент-сервер логикой 216 базы данных и логикой 218 серверного представления. Серверное приложение 210 может быть подконтрольным и приводимым в действие управляющим(и) директивом(ами), получаемым(и) от клиентов 204, 206 в форме сигналов или сообщений по сети 250.

В одном варианте осуществления клиенты 204, 206, каждый, могут содержать электронное устройство, осуществляющее соответствующих веб-клиентов 230, 240. Веб-клиенты 230, 240, каждый, могут содержать, например, экземляры веб-браузера, выполняемого на соответствующих клиентах 204, 206. Веб-браузеры могут также содержать подключаемые модули, веб-приложения и вспомогательные приложения, предназначенные для расширения веб-браузеров с целью поддержки пользовательских служб с сервера 202. Любые ссылки в настоящей заявке на веб-клиентов 230, 240 могут также относиться к функциональным возможностям веб-браузера.

Клиенты 204, 206 могут содержать соответствующие адаптеры 232, 242 клиентов. Каждый из адаптеров 232, 242 клиентов может быть сконфигурирован для использования с данным клиентом 204, 206. Таким образом, серверное приложение 210 и интерпретирующий модуль 212 исполняющей среды не нуждаются в изменении при обращении разных клиентов с использованием разных веб-технологий.

Адаптеры 232, 242 клиентов могут содержать соответствующую логику 238, 248 представления клиента. Логика 238, 248 представления клиента может быть предназначена для показа элементов или представлений интерфейса пользователя на устройстве вывода для клиентов 204, 206, например, цифровом дисплее. Логика 238, 248 представления клиента может быть предназначена для взаимодействия с логикой 214 приложения, логикой 216 базы данных и логикой 218 серверного представления серверного приложения 112, выполняемого на сервере 202, в соответствии с распределенной n-звенной архитектурой, выполненной для серверного приложения 210.

Адаптеры 232, 242 клиентов и соответствующая логика 238, 248 представления клиента могут взаимодействовать с логикой 218 серверного представления, чтобы допускать доступ к серверному приложению 210 через разных клиентов 204, 206. Каждый клиент 204, 206 может осуществлять разные версии логики 218 серверного представления в виде соответствующей логики 238, 248 представления клиента, чтобы соответствовать конкретной конфигурации для клиентов 204, 206. Данная задача может быть выполнена без необходимости перезаписи логики 218 серверного представления и, в частности, бизнес-логики 214 и логики 216 базы данных. Кроме того, логика 218 серверного представления и логика 238, 248 представления клиента могут взаимодействовать таким способом, который уменьшает полезную нагрузку и служебные данные передачи для сети 250, что повышает скорость и производительность при сокращении задержки, соответствующей задержкам передачи данных.

В различных вариантах осуществления логика 218 серверного представления и логика 238, 248 представления клиента могут эффективно взаимодействовать с использованием объекта 260, независимого от графического интерфейса пользователя (GUI), (GUI-независимого объекта 260). GUI-независимый объект 260 позволяет элементам интерфейса GUI, например, экранам (например, приложения Microsoft Windows® Forms), свободно перемещаться между средами рабочего стола и веб-средами. GUI-независимый объект 260 позволяет серверному приложению 210 работать как служба в фоновом режиме, с ожиданием пользовательских событий, которые могут быть получены посредством либо традиционной формы OS (операционной системы), либо формы веб-клиента, и сохранять способность к выполнению событий скриптов, независимо от типа формы, посредством которой было представлено упомянутое событие.

GUI-независимый объект 260 может содержать, наряду с информацией других типов, пользовательские события и любые свойства пользовательских событий, которые могут повлиять на GUI-зависимое визуальное представление адаптерами 232, 242 клиентов, в дополнение к свойствам пользовательских событий, которые могут повлиять на события логики приложения. GUI-независимый объект 260 создается и передается из интерпретирующего модуля 212 исполняющей среды в адаптеры 232, 242 клиентов, где затем визуально представляется на интерфейсе пользователя клиента посредством соответствующей логики 238, 248 представления клиента.

На фиг. 3 показано конкретное осуществление n-звенной системы 300 клиент-сервер. Система 300 клиент-сервер может содержать сервер 302 и клиента 304. Сервер 302 может быть представлен, например, сервером 202, описанным со ссылкой на фиг. 2. Клиент 304 может быть представлен, например, одним или обоими клиентами 204, 206, описанными со ссылкой на фиг. 2.

В наглядном варианте осуществления, показанном в системе 300 клиент-сервер, сервер 302 может выполнять серверное приложение 310. В одном варианте осуществления, например, серверное приложение 310 может быть кодировано с использованием языка программирования Microsoft Dexterity® наряду с языками программирования других подходящих типов. При осуществлении в виде приложения Microsoft Dexterity серверное приложение 310 может быть разбито, в общем, на два отдельных элемента. Первый элемент является интерпретирующим модулем 312 исполняющей среды, который относится к технологическим аспектам среды приложения, например связи с операционной системой (OS) и установления и управления соединением с базой данных 320 посредством диспетчера 316 файлов. Второй элемент является словарем 313 приложения, в котором размещается логика 315 приложения, например правила приложения, бизнес-правила, формы, отчеты, ресурсы, метаданные и код приложения, который включает ответы на пользовательские команды и ввод. Приведенная архитектура изолирует логику 315 приложения от изменений стиля интерфейса UI и расширений платформ, например, обновлений платформенной операционной системы (OS).

Для управления порядком работы приложения используют код sanScript. Код sanScript code обычно пишут небольшими сегментами или скриптами, которые прикрепляют к объектам в словаре 313 приложения, например полям, меню, экранам и формам. Скрипты выполняются, когда пользователь взаимодействует с упомянутым конкретным объектом в приложении. Например, скрипт, применяемый к кнопке, будет выполняться, когда пользователь щелкает мышью на кнопке.

Как показано, клиент 304 может содержать веб-клиент 330. Веб-клиент 330 может быть представлен, например, одним или обоими веб-клиентами 230, 240. Веб-клиент 330 может обеспечивать набор компонентов и служб, ориентированных на интерфейс пользователя и взаимодействие с пользователем, в том числе ввод пользователя и упрощенные элементы управления интерфейса пользователя для использования с серверным приложением 310. Однако для обеспечения плавной миграции в 3-звенную архитектуру требуется решить многочисленные технологические проблемы, возникающие в связи с введением архитектуры веб-клиента, чтобы сделать возможным эффективный интерфейс веб-клиента.

Целью вариантов осуществления, описанных в настоящей заявке, является уменьшение изменений, необходимых для существующих кода и метаданных интерфейса GUI. Для решения некоторых из вышеупомянутых проблем различные варианты осуществления ориентированы на методы для развязки диспетчера 318 интерфейса пользователя и механизма 322 визуального представления операционной системы (OS) с интерпретирующим модулем 312 исполняющей среды. Диспетчер 318 интерфейса пользователя является системным программным обеспечением, которое управляет размещением и внешним видом различных элементов интерфейса пользователя, например, экрана интерфейса GUI, внутри заданной системы интерфейса GUI. Механизм 322 визуального представления OS является системным программным обеспечением для отображения содержимого. Интерпретирующим модулем 312 исполняющей среды является исполняемой версией серверного приложения 310.

Использование форм (или экранов) является базовым компонентом приложения Microsoft Dexterity. Формы являются механизмом, посредством которого пользователь будет взаимодействовать с серверным приложением 310. Когда серверное приложение 310 осуществлено, например, в виде приложения Microsoft Dexterity, экран Microsoft Dexterity обычно содержит код sanScript, соответствующий элементам управления для упомянутого экрана. Код sanScript выполняет, в ответ на заданные пользовательские события, назначенную функцию экрана и элементов управления (например, сохранение транзакции, учет пакета) под управлением интерпретатора 314 скриптов.

В версиях серверного приложения 310, не предназначенных для веб-системы, интерфейс UI работает под управлением диспетчера 318 интерфейса пользователя, который, в свою очередь, обменивается информацией с механизмом 322 визуального представления OS для отображения реального экрана Microsoft Dexterity на экране дисплея, с элементами управления, ранее запланированными разработчиком.

Однако для поддержки перехода к 3-звенной архитектуре веб-клиента системы 300 клиент-сервер диспетчер 318 интерфейса пользователя и механизм 322 визуального представления OS могут быть развязаны с функциями интерпретирующего модуля 312 исполняющей среды. Такая развязка позволяет веб-клиенту 332 осуществить клиентские версии диспетчера 336 интерфейса пользователя и механизма 338 визуального представления на клиенте 304. Упомянутая развязка дополнительно позволяет интерпретирующему модулю 312 исполняющей среды, который выполняется на сервере 302, создавать GUI-независимый объект 360 для использования веб-клиентом 332. При наличии GUI-независимого объекта 360 классический клиент может продолжать обслуживать типичный экран интерфейса GUI (например, экран Microsoft Win32®), между тем как веб-клиенту 330 клиента 304 также предоставляется возможность обслуживания веб-представления того же экрана без необходимости изменения какой-либо базовой логики 315 приложения серверного приложения 310.

Развязка диспетчера 318 интерфейса пользователя и механизма 322 визуального представления OS с интерпретирующим модулем 312 исполняющей среды позволяет экранам (формам) свободно перемещаться между средами, не предназначенными для веб-систем (например, рабочего стола или Win32) и веб-средами. При несвязанных диспетчере 318 интерфейса пользователя и механизме 322 визуального представления OS серверное приложение 310 может выполняться как служба в фоновом режиме, с ожиданием пользовательских событий, которые могут быть получены либо посредством традиционной формы Win32, либо посредством формы веб-клиента, и, по-прежнему, способно выполнять события скриптов, независимо от типа формы, посредством которой оно представлялось.

Для поддержки упомянутой развязки сначала разделяются GUI-зависимые и GUI-независимые слои обработки данных серверного приложения 310. Вместо непосредственного обмена информацией между упомянутыми двумя слоями, метаданные визуального представления и событий представляются с использованием GUI-независимого объекта 360. GUI-независимый объект 360 может содержать любые свойства пользовательских событий, которые могут повлиять на GUI-зависимое визуальное представление адаптером 332 клиента в дополнение к свойствам пользовательских событий, которые могут повлиять на события логики приложения. Затем GUI-независимый объект 360 передается в адаптер 332 клиента (GUI-зависимый), который визуально представляется на экране интерфейса пользователя клиента на дисплее для клиента 304. Примеры некоторых адаптеров 332 клиента могут включать в себя, помимо прочего, Microsoft Silverlight®, HTML, Win32 GDI,.Net Forms, но необязательно ограничены приведенными примерами.

На фиг. 4 показано конкретное осуществление n-звенной системы 400 клиент-сервер. Система 400 клиент-сервер может содержать сервер 402 и клиент 404. Сервер 402 может быть представлен, например, серверами 202, 302, описанными со ссылкой на фиг. 2, 3. Клиент 404 может быть представлен, например, одним или всеми клиентами 204, 206, 304, описанными со ссылкой на фиг. 2, 3.

На сервере 402 может находиться серверное приложение 410, содержащее интерпретирующий модуль 412 исполняющей среды, который может отвечать за исполнение, по меньшей мере, одного слоя приложения или может быть связан с другими компонентами, которые исполняют, по меньшей мере, один слой приложения. Интерпретирующий модуль 412 исполняющей среды может дополнительно содержать интерпретатор 414 скриптов, диспетчер 416 файлов и диспетчер 418 интерфейса пользователя. Интерпретатор 414 скриптов может быть также связан с диспетчером 416 файлов и серверным диспетчером 418 интерфейса пользователя. Диспетчер 416 файлов может быть также связан с базой данных 420.

На клиенте 404 находится веб-клиент 430, выполняющий адаптер 432 клиента. Адаптер 432 клиента может содержать диспетчер 436 интерфейса пользователя и механизм 438 визуального представления для отображения содержимого на интерфейсе пользователя клиента, например интерфейсе пользователя клиента, в соответствии с логикой 238, 248 представления клиента, показанной на фиг. 2.

Фиг. 4 может представлять 3-звенную архитектуру приложения в том смысле, что некоторые слои приложения могут быть распределены между сервером 402 и клиентом 404. Например, логика 238 и/или 248 представления клиента может находиться на клиенте 404, а логика 214 приложения и логика 216 базы данных могут быть распределены на сервере 402, как показано на фиг. 2. В архитектуре, изображенной на фиг. 4, функциональные возможности диспетчера 436 интерфейса пользователя и механизма 438 визуального представления развязаны с интерпретирующим модулем 412 исполняющей среды на сервере 402 и размещены вместе с адаптером 432 клиента на клиенте 404.

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

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

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

Во время работы пользователь может взаимодействовать с интерфейсом пользователя клиента посредством веб-клиента 430. Веб-клиент 430 может содержать веб-браузер, содержащий код интерфейса пользователя для визуального представления веб-содержимого. Веб-клиент 430 может быть выполнен с использованием различных веб-технологий, например, HTML, XHTML и XML наряду с другими технологиями. Примеры веб-клиента 430 могут включать в себя, без ограничения, Internet Explorer® компании Microsoft Corporation, Redmond, шт. Вашингтон наряду с программным обеспечение веб-браузеров других типов.

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

Свойство пользовательского события может быть любым атрибутом, который может быть назначен элементам интерфейса пользователя, например, полям, экранам или графическим объектам, отображаемым в компоновке интерфейса пользователя. Свойство пользовательского события описывает атрибуты стиля представления или формата представления для соответствующих элементов интерфейса пользователя. Свойство пользовательского события может содержать, наряду с информацией других типов, идентификатор (ID) элемента интерфейса пользователя, свойство (например, границу, шрифт, размер шрифта, цвет шрифта, фон, цвет фона, стиль, выравнивание по правому краю, выравнивание по центру, выравнивание по левому краю, одиночный пробел, двойной пробел и т.д.) и значение свойства (например, ложь, истина, 0, 1 и т.п.). Например, экран интерфейса GUI может иметь идентификатор «Window 001» со свойством «изменяемый размер» (Resizeable), установленным в значение «ложь» (False), что означает, что размер экрана интерфейса GUI не может быть изменен пользователем во время выполнения. Выше приведено лишь небольшое число примеров, и любые элементы интерфейса пользователя и свойства интерфейса пользователя можно осуществить таким образом, как требуется для данного варианта осуществления. Варианты осуществления не ограничены в данном отношении.

Веб-клиент 430 может посылать набор измененных свойств 451 пользовательского события в составе сообщения 450 в серверное приложение 410. Диспетчер 418 интерфейса пользователя, работающий на сервере 402, пересылает измененные свойства 451 пользовательского события в составе сообщения 450 в интерпретатор 414 скриптов для обработки. Серверное приложение 410 может обеспечить, чтобы входные данные приложения и состояния приложения были надлежащими перед выполнением любой логики приложения для серверного приложения 410. Затем интерпретатор 414 скриптов может установить связь с диспетчером 416 файлов, который имеет доступ к базе данных 420, при необходимости выполнения любых правил приложения, проистекающих из измененных свойств 451 пользовательского события в сообщении 450, полученном от клиента 404. После выполнения соответствующей логики приложения интерпретирующий модуль 412 исполняющей среды может создать GUI-независимый объект 452. GUI-независимый объект 452 может содержать, наряду с другой информацией, обновленные свойства 454 пользовательского события. Диспетчер 418 интерфейса пользователя, осуществленный сервером 402, может послать GUI-независимый объект 452 вместе с любыми обновленными свойствами 454 пользовательского события обратно клиенту 404. Затем, адаптер 432 клиента, посредством диспетчера 436 интерфейса пользователя и механизма 438 визуального представления, может обновить ранее визуализированное изображение, с использованием GUI-независимого объекта 452, вместе с обновленными свойствами 454 пользовательского события, сформированными серверным приложением 410 и полученными из него.

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

На фиг. 5 показан вариант осуществления логической блок-схемы 500 последовательности операций. Логическая блок-схема 500 последовательности операций может пояснять операции, выполняемые в соответствии с, по меньшей мере, одним вариантом осуществления. Например, логическая блок-схема 500 последовательности операций может пояснять операции, выполняемые веб-клиентом 430 и/или серверным приложением 410.

В логической блок-схеме 500 последовательности операций пользователь взаимодействует с веб-клиентом, выполняемым в интерфейсе пользователя на стороне клиента, на этапе 502. Например, веб-клиент 430 может получать ввод пользователя в форме, по меньшей мере, одной управляющей директивы, полученной из устройства ввода, которая влияет на, по меньшей мере, один элемент элемента пользователя в интерфейсе пользователя, представленном механизмом 438 визуального представления. Ввод пользователя может взаимодействовать с элементом интерфейса пользователя и тем самым вызывать пользовательское событие. Например, пользователь может выбрать поле на форме, представленной на экране интерфейса GUI, и изменить значение для поля.

В логической блок-схеме 500 последовательности операций адаптер клиента, выполняемый в настоящем случае, может интерпретировать управляющую директиву, представляющую пользовательские события с обеспечением совместимости с серверным приложением, выполняемым на сервере, на этапе 504. Например, адаптер 432 клиента, выполняемый веб-клиентом 430, может интерпретировать пользовательские события таким же образом, как серверное приложение 410. Пользовательские события могут включать в себя, по меньшей мере, взаимодействие пользователя с интерфейсом пользователя, выполняемым на веб-клиенте 430, например, но без ограничения, щелчок мышью на кнопке, заполнение текстового поля и т.д.

В логической блок-схеме 500 последовательности операций операция интерпретации на этапе 504 проверяет вновь введенные свойства пользовательского события, чтобы определить, изменились ли свойства пользовательского события на этапе 506 настолько, чтобы потребовалось уведомить серверное приложение. Например, адаптер 432 клиента может проверять любые вводы пользователя и соответствующие изменения свойств затрагиваемых элементов интерфейса пользователя, чтобы определить, изменились ли свойства пользовательского события свыше некоторой пороговой величины. Например, наведение на поле для его активизации может быть недостаточным действием для запуска каких-либо изменений свойств пользовательского события, а выбор поля будет достаточным действием для уведомления серверного приложения 410.

В логической блок-схеме 500 последовательности операций, в тех случаях, когда требуется уведомление, адаптер клиента может посылать любые измененные свойства пользовательского события, ожидающие очереди на обработку, в серверное приложение на этапе 508. Например, адаптер 432 клиента может посылать измененные свойства 451 пользовательского события в составе сообщения 450 в серверное приложение 410 по сети 250. В некоторых вариантах осуществления адаптер 432 клиента может посылать несколько наборов измененных свойств 451 пользовательского события для нескольких пользовательских событий в составе сообщения 450 в серверное приложение 410, исполняемое на сервере 402. Упомянутая «пакетная» передача может быть полезна во многих отношениях, в том числе для поддержки серверного приложения 410 при синхронизации пользовательских событий. Например, интерпретатор 414 скриптов может синхронизировать во времени выполнение различных скриптов (например, прескриптов, скриптов изменений, постскриптов и т.п.), чтобы обеспечить точную последовательность обновлений серверного приложения 410. Пакетная передача может также уменьшить объем служебных данных передачи за счет посылки меньшего числа сообщений 450 по сети 250. Существуют также другие преимущества, и варианты осуществления в этом отношении не ограничены.

В логической блок-схеме 500 последовательности операций модуль исполняющей среды, выполняемый на сервере, может гарантировать надлежащие входные данные/состояния для серверного приложения на этапе 510 до того, как события бизнес-логики могут быть выполнены на этапе 512. Например, интерпретирующий модуль 412 исполняющей среды, исполняемый на сервере 402, может гарантировать надлежащие входные данные приложения и состояния приложения для серверного приложения 410 до выполнения любого приложения или бизнес-логики.

В логической блок-схеме 500 последовательности операций обновленные свойства пользовательского события, полученные в результате выполнения бизнес-логики, вместе с GUI-независимым объектом, могут быть переданы обратно в адаптер клиента на этапе 514. Например, обновленные свойства 454 пользовательского события, полученные в результате выполнения логики приложения или бизнес-логики, вместе с GUI-независимый объектом 452, могут пересылаться из серверного приложения 410 в веб-клиента 430 для передачи обратно в адаптер 432 клиента.

В логической блок-схеме 500 последовательности операций адаптер клиента может после этого обновлять ранее визуализированное изображение в интерфейсе пользователя клиента на этапе 516 с использованием обновленных свойств пользовательского события и GUI-независимого объекта. Например, адаптер 432 клиента может получать GUI-независимый объект 452, и механизм 438 визуального представления может обновлять ранее визуализированное изображение в интерфейсе пользователя клиента с использованием обновленных свойств 454 пользовательского события и GUI-независимого объекта 452.

На фиг. 6A приведен вариант осуществления способа, посредством которого возможно создание GUI-независимого объекта 452 для адаптера 432 клиента с использованием данных из серверного приложения 410. Как изложено выше в описании, адаптер 432 клиента может получать GUI-независимый объект 452, имеющий обновленные свойства 454 пользовательского события. Обновленные свойства 454 пользовательского события могут содержать, наряду с другой информацией, метаданные 602 GUI-независимого объекта 452. В одном варианте осуществления метаданные 602 GUI-независимого объекта 452 могут содержать фиксированные или статические метаданные. Обновленные свойства 454 пользовательского события могут дополнительно содержать коллекцию 604 свойств/значений. Фиксированные/статические метаданные 602 GUI-независимого объекта могут быть объединены с GUI-независимой коллекцией 604 свойств/значений для образования GUI-независимого объекта 606, который может быть визуально представлен в веб-клиенте 430 посредством адаптера 432 клиента.

На фиг. 6B приведен вариант осуществления способа, посредством которого возможно создание конкретного GUI-независимого объекта 452 с использованием конструкций, показанных на фиг. 6A. Обновленные свойства 454 пользовательского события могут содержать, наряду с другой информацией, метаданные 612 объекта и коллекцию 614 свойств/значений.

Обновленные свойства 454 пользовательского события могут содержать метаданные 612 объекта, содержащие, по меньшей мере, один элемент интерфейса пользователя. В приведенном примере метаданные 612 объекта содержат три элемента интерфейса объекта в форме полей, обозначенных поле A, поле B и поле C. Каждое из полей A, B и C показаны, в общем, в виде текстового поля с границей вокруг текста со шрифтом по умолчанию, состоящего из фраз «Поле A», «Поле B» и «Поле C», соответственно.

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

При объединении, в результате, может быть получен GUI-независимый объект 616. Как показано в GUI-независимом объекте 616, поле A не изменено из обобщенной версии метаданных, так как ни одно из его свойств или значений не было изменено в коллекции 614 свойств/значений. Поле B показано без его границы, так для свойства «граница» было установлено значение «ложь» («False») в коллекции 614 свойств/значений. Текст в поле C показан жирным, так как для свойства «жирный» было установлено значение «истина» («True») в коллекции 614 свойств/значений. В таком случае объект 616 может быть визуально представлен на клиенте 404 в веб-клиенте 430 посредством механизма 438 визуального представления адаптера 432 клиента.

На фиг. 7 представлен вариант осуществления логической блок-схемы 700 последовательности операций. Логическая блок-схема 700 последовательности операций может пояснить операции, выполняемые в соответствии с, по меньшей мере, одним вариантом осуществления. Например, логическая блок-схема 700 последовательности операций может пояснить операции, выполняемые веб-клиентом 430 и/или серверным приложением 410 с целью восстановления адаптера 432 клиента, который был разрушен.

Другое преимущество вариантов осуществления, предложенных в настоящем описании, состоит в том, что визуализированное изображение в данном клиенте 404 можно восстановить, если адаптер 432 клиента разрушен. Если адаптер 432 клиента разрушается, то визуализированное изображение, состоящее из различных GUI-зависимых объектов 452, также разрушается. Однако серверное приложение 410 может продолжать удерживать состояние в форме GUI-независимых объектов 452. Как показано на фиг. 7, пользователь может взаимодействовать с веб-клиентом 430, выполняемым в интерфейсе пользователя на стороне клиента, для создания нового экземпляра адаптера 432 клиента на этапе 702. Затем, новый экземпляр адаптера 432 клиента может восстановить соединение с серверным приложением 410 на этапе 704. После восстановления соединения серверное приложение 410 может по-прежнему поддерживать последнее известное состояние для всех GUI-независимых объектов 452. На этапе 706 последнее известное состояние для всех GUI-независимых объектов 452 передается обратно клиенту 404 и принимается им 404. После этого последнее известное состояние для всех GUI-независимых объектов 452 может быть синхронизировано с веб-клиентом 430 клиента 404 на этапе 708. В результате, текущее состояние для адаптера 432 клиента может быть эффективно восстановлено с использованием информации, сохраняемой серверным приложением 410.

Выше приведено описание того, как механизм 438 визуального представления может быть развязан с интерпретирующим модулем 412 исполняющей среды, чтобы создавать GUI-независимый объект 452, который можно визуально представлять как представление интерфейса пользователя, например, в виде интерфейса пользователя (UI) Microsoft Windows® Forms или Microsoft Silverlight®, наряду с другими представлениями. Нижеприведенное описание относится, в основном, к тому, каким образом GUI-независимый объект 452 может быть преобразован в визуализируемое изображение представления интерфейса пользователя, например, интерфейс пользователя (UI) Microsoft Windows Forms или Microsoft Silverlight.

В соответствии с одним вариантом осуществления, система 400 может преобразовывать метаданные 602 GUI-независимого объекта, сформированные интерпретирующим модулем 412 исполняющей среды в шаблон интерфейса пользователя, при сохранении исходного кода метаданных в качестве базы основного кода. GUI-независимый объект 452 содержит метаданные как визуального представления, так и события. Как изложено ранее, GUI-независимый объект 452 может быть сформирован непосредственно из интерпретирующего модуля 412 исполняющей среды или из модели объекта, которая может обеспечивать сведения о GUI-независимом объекте 452.

Следует вспомнить, что диспетчер 418 интерфейса пользователя, как часть интерпретирующего модуля 412 исполняющей среды, по-прежнему должен выполнять задачу обработки событий интерфейса пользователя (UI), тогда как механизм 438 визуального представления должен выполнять задачу показа интерфейса пользователя на клиенте 404 для конечного пользователя. Теперь, когда интерпретирующий модуль 412 исполняющей среды освобожден от выполнения, в первую очередь, упомянутых задач, полученный GUI-независимый объект 452 обрабатывается адаптером 432 клиента создания любого из интерфейсов. Упомянутая обработка может обеспечиваться посредством осуществления, например, процессора обработки шаблонов.

В различных вариантах осуществления процессор обработки шаблонов принимает обобщенное представление экрана интерфейса GUI и может располагать возможностью применения версии расширяемого языка разметки (XML) его содержимого (например, полей, кнопок и событий), которые могут быть известны как шаблон экрана интерфейса GUI. Кроме того, процессор обработки шаблонов может располагать возможностью применения версии, известной как базовый шаблон, который интерпретирующий модуль 412 исполняющей среды по-прежнему может отображать в классическом клиенте, который выполняет базовое преобразование, по меньшей мере, в случаях, когда для экрана не имеется никакого шаблона интерфейса GUI. Экран и базовые шаблоны интерфейса GUI содержат метаданные и содержимое, которое характеризует компоновку экрана интерфейса GUI. Шаблон экрана интерфейса GUI связан с базовым шаблоном, но является его настроенной версией.

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

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

Второй шаблон можно именовать шаблоном экрана интерфейса GUI. Шаблон экрана интерфейса GUI может содержать шаблон для данного экрана интерфейса GUI. Компоновка шаблона экрана интерфейса GUI может переопределять базовую компоновку шаблона для разделов как заголовка, так и содержимого. Переопределенная компоновка содержимого может быть табличной, например, компоновкой сетки, и/или сгруппированной, например, компоновкой типа accordion (раздвижной). Новая компоновка может быть задана в файлах XML. Компоновка шаблона экрана интерфейса GUI может объединять несколько экранов интерфейса GUI в один экран и может быть конкретной для экрана интерфейса GUI, который упомянутая компоновка изменяет.

В контексте настоящего изобретения термин «экран интерфейса GUI» может относиться к элементу интерфейса пользователя, предназначенному для использования некоторой части или всего поля представления или области отображения дисплея. Например, некоторые элементы интерфейса пользователя предназначены для использования только участка или подсекции дисплея, например, обведенной границей, рамкой или другими оконными элементами интерфейса пользователя на дисплее. В некоторых случаях экран интерфейса GUI может содержать набор элементов управления интерфейсом пользователя (UI), чтобы предоставлять пользователю возможность увеличивать, уменьшать или перемещать экран интерфейса GUI по полю представления дисплея или полностью удалять экран интерфейса GUI из поля представления дисплея. Примеры экрана интерфейса GUI могут включать в себя такие элементы интерфейса пользователя, как «окно» интерфейса GUI, сформированное, например, приложением интерфейса пользователя Microsoft Windows или Microsoft Window Form, наряду с другими приложениями и операционными системами.

Процессор обработки шаблонов может применять вышеописанные шаблоны, наряду с другими шаблонами, для формирования настроенной версии GUI-независимого объекта, который содержит сведения о компоновке экрана интерфейса GUI. Механизм 438 визуального представления, вместе с логикой преобразования интерфейса пользователя (UI), может получать новую настроенную версию GUI-независимого объекта 452 и формировать новое настроенное представление интерфейса GUI (например, окно интерфейса GUI) для клиента 404 для представления конечному пользователю. Механизм 438 визуального представления может сопоставлять атрибуты объекта интерфейса GUI с элементами управления и свойствами (например, заголовок → лента) интерфейса GUI и формировать конкретные элементы управления интерфейса GUI и компоновку, требуемую для клиента 404.

На фиг. 8A показана блок-схема системы 800 обработки шаблона для обработки шаблона, характеризующего компоновку объекта интерфейса GUI в соответствии с одним вариантом осуществления. В одном варианте осуществления система 800 обработки шаблона может быть осуществлена как составная часть серверного приложения 810 для сервера 802. Серверное приложение 810 и сервер 802 могут быть представлены, например, соответствующими серверным приложением 410 и сервером 402, описанными со ссылкой на фиг. 4. Однако можно понять, что система 800 обработки шаблона может быть также осуществлена в различных других частях n-звенной архитектуры клиент-сервер, в том числе, например, в клиентском приложении 830 клиента 804.

В одном варианте осуществления клиентское приложение 830 может быть представлено, например, веб-клиентом 430 и/или адаптером 432 клиента, относящимся к клиенту 404, описанному со ссылкой на фиг. 4. Кроме того, или в качестве альтернативы, клиентское приложение 830 может быть осуществлено в виде клиентского приложения, отличающегося от клиентского приложения 430, например, версии серверного приложения 810 под конкретный процессор или для настольной системы. Возможно также осуществление других клиентских приложений. Варианты осуществления не ограничены в данном отношении.

Как изложено выше со ссылкой на фиг. 4, в серверное приложение 430 может быть послано сообщение 450 с измененными свойствами 451 пользовательского события. Затем, интерпретирующий модуль 412 исполняющей среды серверного приложения 410 обрабатывает измененные свойства 451 пользовательского события для создания GUI-независимого объекта 452.

В наглядном варианте осуществления, показанном на фиг. 8A, аналогичный процесс может быть представлен пользовательскими событиями 804, которые клиентское приложение 830 клиента 804 может пересылать в интерпретирующий модуль 850 исполняющей среды посредством диспетчера 806 интерфейса пользователя, чтобы создать GUI-независимый объект 812. Однако, в этот момент, GUI-независимый объект 812 является промежуточным GUI-независимым объектом и не готов для представления клиентским приложением 830. Для уточнения GUI-независимого объекта 812 для использования конкретным клиентским приложением 830 GUI-независимый объект 812 может быть передан в процессор 814 обработки шаблонов для дополнительной обработки. Затем, процессор 814 обработки шаблонов может применять базовый шаблон 816 и шаблон 818 экрана интерфейса из GUI-независимого объекта 812.

Базовый шаблон 816 может применять базовое преобразование без обязательного создания новой компоновки шаблона для каждого экрана интерфейса GUI. Базовый шаблон 816 может применить логику преобразования для создания одной новой компоновки, показанной как представление 811 интерфейса GUI. В приведенном варианте осуществления представление 811 интерфейса GUI не предназначено для объединения нескольких экранов интерфейса GUI в один экран.

Компоновка шаблона экрана интерфейса GUI может переопределять базовую компоновку шаблона базового шаблона 816 для разделов как заголовка, так и содержимого. Переопределенная компоновка содержимого может быть табличной, например, компоновкой сетки, и/или сгруппированной, например, компоновкой типа accordion (раздвижной). В одном варианте осуществления новая компоновка может быть задана в файлах XML наряду с другими подходящими форматами компоновки для веб-систем. Компоновка шаблона экрана интерфейса GUI может объединять несколько экранов интерфейса GUI в один экран и может быть предназначена конкретно для экрана интерфейса GUI, который упомянутая компоновка изменяет.

Затем, процессор 814 обработки шаблонов может применить вышеописанные шаблоны 816, 818 для формирования нового и в высокой степени настроенного GUI-независимого объекта 820, который содержит сведения о компоновке экрана интерфейса GUI. Новый GUI-независимый объект 820 может содержать более конкретное осуществление для GUI-независимого объекта 812, который, в свою очередь, представлен GUI-независимыми объектами 360, 452, описанными со ссылкой на соответствующие фиг. 3, 4. Новый GUI-независимый объект 820 передается обратно из серверного приложения 810 в механизм 822 визуального представления клиентского приложения 830, исполняемого на клиенте 804.

Механизм 822 визуального представления принимает новый GUI-независимый объект 820 и выполняет логику преобразования интерфейса пользователя (UI), предназначенную для формирования настроенного нового представления 824 интерфейса GUI для конечного пользователя. Механизм 822 визуального представления может сопоставлять атрибуты объекта интерфейса GUI с элементами управления и свойствами (например, заголовок → лента) интерфейса GUI и формировать конкретные элементы управления интерфейса GUI и компоновку, требуемую для клиентского приложения.

На фиг. 8B, 8C приведены более подробные изображения для соответствующих представлений 811, 824 интерфейса GUI. Например, экран интерфейса GUI, характеризующий базовый шаблон, может быть показан в представлении 811 интерфейса GUI на фиг. 8B, и экран интерфейса GUI, полученный по шаблону экрана интерфейса GUI, может быть показан в представлении 824 интерфейса GUI на фиг. 8C.

В наглядных вариантах осуществления, показанных на фиг. 8B, 8C, представление 811 интерфейса GUI (фиг. 8B), построенное по базовому шаблону 816, может иметь вид, похожий на, но все же отличающийся от представления 824 интерфейса GUI (фиг. 8C), построенного по шаблону 818 экрана. Следует помнить, что шаблон 818 экрана будет замещать базовый шаблон 816. То есть сначала может применяться базовый шаблон 816, и затем может применяться шаблон 818 экрана для настройки базового шаблона 816. В наглядном примере на фиг. 8B (представление базового шаблона) и 8C (представление шаблона экрана) многие из кнопок и рамок полей переупорядочены. Например, нижние левые кнопки в представлении 811 интерфейса GUI, построенном по базовому шаблону 816, перемещены в строку меню на верхнем левом участке представления 824 интерфейса GUI, построенного по шаблону 818 экрана. Оба представления 811 (фиг. 8B) и 824 (фиг. 8C) интерфейса GUI иллюстрируют ленточное представление 826 интерфейса UI. Лента является большой панелью инструментов, которая содержит группы меню и кнопок, организованных по функциям. Каждая кнопка функционально связана с вкладкой. Как показано в представлении 824 интерфейса GUI на фиг. 8C, вкладка называется «поставщик» («Vendor»). Кроме того, компоновка вкладки поставщика организована в виде двух разделов. Раздел 1 обозначен как «Общий» («General») 828, а раздел 2 обозначен как «Адреса» («Addresses») 860. Приведенная компоновка отличается от представления 811 интерфейса GUI на фиг. 8B тем, что вкладки («Адреса» (Addresses), «Учетные записи» (Accounts), «Параметры» (Options), «Эл.почта» (Email), «Удержание» (Withholding)) в представлении 824 интерфейса GUI заменили кнопки («Параметры», «Адрес», «Учетные записи», «Эл.почта») в представлении 811 интерфейса GUI. Можно заметить, что между представлениями 811, 824 интерфейса GUI существуют другие отличия в виде других выполненных и возможных модификаций и изменений. Таким образом, система 800 обработки шаблона может обеспечивать представления интерфейса GUI, настроенные для разных веб-клиентов (например, веб-клиентов 230, 240), применяющих разные адаптеры клиентов (например, адаптеры 232, 242 клиентов), при этом настроенные представления интерфейсы GUI получены из собственных представлений интерфейса GUI, обеспеченных серверным приложением (например, 410, 810).

На фиг. 9 приведена логическая блок-схема 900 последовательности операций. Логическая блок-схема 900 последовательности операций может пояснять операции, выполняемые в соответствии с, по меньшей мере, одним вариантом осуществления. Например, логическая блок-схема 900 последовательности операций может пояснять операции, выполняемые серверным приложением 810 и/или клиентским приложением 830, как показано на фиг. 8. В качестве дополнения или альтернативы, логическая блок-схема 900 последовательности операций может пояснять операции, выполняемые серверным приложением 410 и/или веб-клиентом 430, как показано на фиг. 4. Варианты осуществления не ограничены в данном отношении.

В логической блок-схеме 900 последовательности операций пользователь взаимодействует с веб-клиентом, выполняемым в интерфейсе пользователя на стороне клиента, чтобы ввести пользовательские события. Этапы 902, 904 и 906 могут представлять сокращенное представление логического процесса, который более полно описан на фиг. 5.

В логической блок-схеме 900 последовательности операций, при формировании GUI-независимого объекта модулем исполняющей среды на этапе 906, GUI-независимый объект может передаваться в процессор обработки шаблонов на этапе 908. Например, GUI-независимый объект 812 может быть передан клиентским приложением 830 в процессор 814 обработки шаблонов, выполняемый в серверном приложении 810, для дополнительной обработки.

В логической блок-схеме 900 последовательности операций процессор обработки шаблонов может применить сформированные базовый шаблон и шаблон экрана для формирования нового объекта интерфейса GUI на этапе 912. Например, процессор 814 обработки шаблонов может применять сформированные базовый шаблон 816 и шаблон 818 экрана для формирования настроенного нового GUI-независимого объекта 820.

В логической блок-схеме 900 последовательности операций новый GUI-независимый объект может быть послан обратно клиенту на этапе 914. Например, настроенный новый GUI-независимый объект 820 может быть послан обратно в клиентское приложение 830 (по сети 250), в котором упомянутый объект может быть передан в механизм 822 визуального представления для дальнейшей обработки.

В логической блок-схеме 900 последовательности операций механизм визуального представления может преобразовывать объект интерфейса GUI и может формировать новый экран интерфейса GUI на этапе 916. Например, механизм 822 визуального представления может преобразовывать GUI-независимый объект 820 и может формировать настроенное представление 824 интерфейса GUI, которое визуализируется клиентским приложением 830 (или адаптером клиента или клиентской операционной системой (OS)).

На фиг. 10 приведен вариант осуществления примерной архитектуры 1000 вычислительной системы, пригодной для выполнения различных вышеописанных вариантов осуществления. Архитектура 1000 вычислительной системы содержит различные общие вычислительные элементы, например, по меньшей мере, один процессор, сопроцессор, блок памяти, набор микросхем, контроллер, периферийное устройство, интерфейс, генератор, счетчик времени, видеокарту, звуковую карту, компонент ввода/вывода (I/O) мильтимедиа и т.д. Однако варианты осуществления не ограничены осуществлением архитектуры 1000 вычислительной системы.

Как показано на фиг. 10, архитектура 1000 вычислительной системы содержит процессорный блок 1004, системную память 1006 и системную шину 1008. Процессорный блок 1004 может быть любым из различных коммерческих процессоров. Сдвоенные микропроцессоры и другие мультипроцессорные архитектуры также можно применить как процессорный блок 1004. Системная шина 1008 обеспечивает интерфейс для системных компонентов, содержащих, но без ограничения, системную память 1006 для процессорного блока 1004. Системная шина 10010 может быть любой шинной структурой из нескольких типов, которая может быть дополнительно соединена с шиной памяти (с контроллером памяти или без него), периферийной шиной и локальной шиной с использованием любой из множества различных коммерческих шинных архитектур.

Системная память 1006 может содержать блоки памяти различных типов, например постоянную память (ROM), оперативную память (RAM), динамическую оперативную память (DRAM), память DRAM с двойной скоростью (DDRAM), синхронную память DRAM (SDRAM), статическую оперативную память (SRAM), программируемую постоянную память (PROM), стираемую программируемую постоянную память (EPROM), электрически стираемую программируемую постоянную память (EEPROM), флэш-память, память на полимере, например память на ферроэлектрическом полимере, память на аморфных полупроводниках, память на фазовых переходах или ферроэлектрическая память, помять, выполненная по технологии кремний-оксид-нитрид-оксид-кремний (SONOS), магнитные или оптические карты или носитель любого другого типа, пригодный для хранения информации. В наглядном варианте осуществления, показанном на фиг. 10, системная память 1006 может содержать энергонезависимую память 1010 и/или энергозависимую память 1012. Базовая система ввода/вывода (BIOS) может храниться в энергонезависимой памяти 1010.

Компьютер 1002 может содержать компьютерно-считываемые носители данных различных типов, в том числе внутренний накопитель 1014 на жестком диске (HDD), накопитель 1016 на магнитных дискетах (FDD) для считывания со съемного магнитного диска 10110 или записи на него и накопитель 1020 на оптическом диске для считывания со съемного оптического диска 1022 (например, постоянной памяти на компакт-диске (CD-ROM) или цифрового видеодиска (DVD)) или записи на него. Накопители HDD 1014, FDD 1016 и накопитель 1020 на оптическом диске могут быть подсоединены, соответственно, интерфейсом 1024 накопителя HDD, интерфейсом 1026 накопителя FDD и интерфейсом 10210 оптического накопителя к системной шине 100108. Интерфейс 1024 накопителя HDD для вариантов внешнего осуществления накопителя может содержать, по меньшей мере, какую-то одну или обе из технологий интерфейсов универсальной последовательной шины (USB) и IEEE 1394.

Накопители и соответствующие компьютерно-считываемые носители обеспечивают энергозависимое и/или энергонезависимое хранение данных, структур данных, компьютерно-исполняемых команд и т.д. Например, многие из программных модулей могут храниться в накопителях и блоках 1010, 1012 памяти, в том числе операционная система 1030, по меньшей мере, одна прикладная программа 1032, другие программные модули 1034 и данные 1036 программ. По меньшей мере, одна прикладная программа 1032, другие программные модули 1034 и данные 1036 программ могут содержать, например, компоненты программного обеспечения для систем 200, 300 и 400 клиент-сервер.

Пользователь может вводить команды и информацию в компьютер 1002 посредством, по меньшей мере, проводного/беспроводного устройства ввода, например клавиатуры 10310 и указывающего устройства, например мыши 1040. Другие устройства ввода могут содержать микрофон, инфракрасное (ИК) дистанционное устройство управления, джойстик, игровую панель, перо, сенсорный экран и т.п. Упомянутые и другие устройства ввода часто подсоединены к процессорному блоку 1004 посредством интерфейса 1042 устройства ввода, который соединен с системной шиной 10010, но могут быть подсоединены другими интерфейсами, например, параллельным портом, последовательным портом IEEE 1394, игровым портом, портом USB, ИК интерфейсом и т.д.

По меньшей мере, один монитор 1044 или устройство отображения другого типа также подсоединен к системной шине 1008 через интерфейс, например видеоадаптер 1046. Кроме монитора 1044 компьютер обычно содержит другие периферийные устройства вывода, например, динамики, принтеры и т.д. По меньшей мере, один монитор 1045 также может быть подсоединен к системной шине 10010 через интерфейс 1042 устройства ввода и/или концентратор, например, USB-концентратор 1043. Мониторы 1045 могут содержать различные компоненты, например, видеокамеру, набор микрофонов, датчики касания, датчики движения, динамики и т.д. Компоненты могут быть подсоединены к интерфейсу 1042 устройства ввода через USB-концентратор 1043.

Компьютер 1002 может работать в сетевой среде с использованием логических соединений через проводные и/или беспроводные средства связи с, по меньшей мере, одним удаленным компьютером, например удаленным компьютером 10410. Удаленный компьютер 10410 может быть рабочей станцией, серверным компьютером, маршрутизатором, персональным компьютером, переносным компьютером, микропроцессорным развлекательным бытовым устройством, равноправным устройством или другим обычным сетевым узлом и обычно содержит многие или все элементы, описанные в связи с компьютером 1002, несмотря на то, что для краткости показана(о) только память/запоминающее устройство 1050. Показанные логические соединения включают в себя проводные/беспроводные возможности подключения к локальной сети (LAN) 1052 и/или более крупным сетям, например, глобальной сети (WAN) 1054. Упомянутые сетевые среды LAN и WAN обычны для офисов и компаний и поддерживают компьютерные сети предприятий, например, внутренние сети, из которых все могут подключаться к глобальным сетям связи, например, сети Internet.

При использовании в сетевой среде LAN компьютер 1002 подсоединен к сети LAN 1052 посредством проводного и/или беспроводного сетевого интерфейса или адаптера 1056 связи. Адаптер 1056 может поддерживать проводную и/или беспроводную связь с сетью LAN 1052, которая также может содержать точку беспроводного доступа, расположенную в упомянутой сети, для связи с беспроводной функциональной возможностью адаптера 1056.

При использовании в сетевой среде WAN компьютер 1002 может содержать модем 10510 или подсоединен к коммуникационному серверу в сети WAN 1054, или располагает другим средством для установления связи по сети WAN 1054, например, по сети Internet. Модем 10510, который может быть внутренним или внешним и проводным и/или беспроводным устройством, подсоединяется к системной шине 10010 посредством интерфейса 1042 устройства ввода. В сетевой среде программные модули, описанные в связи с компьютером 1002, или их части могут храниться в удаленной(ом) памяти/запоминающем устройстве 1050. Следует понимать, что показанные сетевые соединения являются примерными, и возможно применение других средств установления линии связи между компьютерами.

Компьютер 1002 функционально предназначен для осуществления связи с проводными и беспроводными устройствами или реальными объектами с использованием семейства стандартов IEEE 802, например, беспроводными устройствами, размещенными с возможностью осуществления беспроводной связи (например, методами модуляции в радиоканале по стандарту IEEE 802.11) с, например, принтером, сканером, настольным и/или переносным компьютером, персональным цифровым секретарем (PDA), спутником связи, любой единицей оборудования или любым местом, соответствующим метке, обнаруживаемой беспроводным методом, (например, киоском, табло новостей, помещением для отдыха) и телефоном. Упомянутая связь включает в себя, по меньшей мере, беспроводные технологии Wi-Fi (или Wireless Fidelity), WiMax и Bluetooth™. Таким образом, связь может быть предварительно заданной структурой, как, например, в случае обычной сети, или просто специальной связью между, по меньшей мере, двумя устройствами. Сети Wi-Fi используют технологии радиосвязи, называемые IEEE 802.11x (a, b, g и т.п.), для обеспечения защищенных, надежных, скоростных соединений. Сеть Wi-Fi можно использовать для соединения компьютеров между собой, с сетью Internet и с проводными сетями (которые используют каналы передачи и функции, установленные стандартом IEEE 802.3).

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

Как показано на фиг. 11, архитектура 1100 системы связи содержит, по меньшей мере, одного клиента 1102 и, по меньшей мере, один сервер 1104. Клиенты 1102 могут осуществлять веб-клиента 430. Серверы 1104 могут осуществлять интерпретирующий модуль 412 исполняющей среды. Клиенты 1102 и серверы 1104 функционально соединены с соответствующими, по меньшей мере, одним хранилищем 1108 данных клиента и хранилищем 1110 данных сервера, которые можно использовать для хранения информации, локальной для соответствующих клиентов 1102 и серверов 1104, например, файлы cookie и/или соответствующую контекстную информацию.

Клиенты 1102 и серверы 1104 могут обмениваться информацией между собой с использованием платформы 1106 связи. Платформа 1106 связи может применять любые общеизвестные методы связи, например, методы, пригодные для применения с сетями с коммутацией пакетов (например, такими общедоступными сетями, как сеть Internet, такими ведомственными сетями, как внутренняя сеть предприятия, и т.д.), сетями с коммутацией каналов (например, коммутируемой телефонной сетью общего пользования) или комбинированной системой из сетей с коммутацией пакетов и сетей с коммутацией каналов (с подходящими шлюзами и трансляторами). Клиенты 1102 и серверы 1104 могут содержать стандартные элементы связи различных типов, выполненные с возможностью совмещения с платформой 1106 связи, например, по меньшей мере, один связной интерфейс, один сетевой интерфейс, одну связную интерфейсную плату (NIC), одну радиостанцию, один беспроводной передатчик/приемник (приемопередатчик), один проводной и/или беспроводной канал передачи, один физический соединитель и т.д. Например, и без ограничения, канал передачи содержит проводной канал передачи и беспроводной канал передачи. Примеры проводных каналов передачи могут включать в себя провод, кабель, металлические проводники, печатные платы (PCB), объединительные платы, многовходовые системы коммутации, полупроводниковый материал, витую проводную пару, коаксиальный кабель, волоконно-оптический кабель, распространяющийся сигнал и т.д. Примеры беспроводных каналов передачи могут включать в себя каналы передачи акустическим излучением в спектре радиочастотного (РЧ) излучения, инфракрасного излучения и другие беспроводные каналы передачи. Один возможный вариант связи между клиентом 1102 и сервером 1104 может быть в форме пакета данных, адаптированного для передачи между, по меньшей мере, двумя компьютерными процессами. Пакет данных может содержать, например, файл cookie и/или соответствующую контекстную информацию.

Различные варианты осуществления могут быть выполнены с использованием аппаратных элементов, программных элементов или комбинации тех и других элементов. Примеры аппаратных элементов могут включать в себя устройства, логические устройства, компоненты, процессоры, микропроцессоры, схемы, схемные элементы (например, транзисторы, резисторы, конденсаторы, катушки индуктивности и т.д.), интегральные схемы, специализированные интегральные схемы (ASIC), программируемые логические устройства (PLD), процессоры цифровых сигналов (DSP), программируемые пользователем вентильные матрицы (FPGA), блоки памяти, логические вентили, регистры, полупроводниковые устройства, интегральные схемы, микросхемы, наборы микросхем и т.д. Примеры программных элементов могут включать в себя компоненты программного обеспечения, программы, приложения, компьютерные программы, прикладные программы, системные программы, машинные программы, программное обеспечение операционной системы, программное обеспечение промежуточного слоя, встроенное программное обеспечение, модули системы программного обеспечения, стандартные программы, подпрограммы, функции, способы, процедуры, интерфейсные программы, программные интерфейсы приложений (API), наборы команд, код вычислений, машинный код, сегменты кодов, сегменты машинного кода, слова, значения, символы или любую их комбинацию. Определение, следует ли вариант осуществления выполнять с использованием аппаратных элементов и/или программных элементов, может изменяться в зависимости от любого числа факторов, например, требуемой скорости выполнения вычислений, уровней мощности, теплоустойчивости, бюджета цикла обработки, скорости передачи входных данных, скорости передачи выходных данных, ресурсов памяти, скоростей шины данных и других проектных ограничений или ограничений рабочих характеристик, как требуется для данного осуществления.

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

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

Некоторые варианты осуществления могут быть описаны с использованием выражения «связанный» и «соединенный» вместе с их производными. Упомянутые термины необязательно предполагают синонимичность между собой. Например, некоторые варианты осуществления могут быть описаны с использованием терминов «соединенный» и/или «связанный» для указания, что, по меньшей мере, два элемента находятся в непосредственном физическом или электрическом контакте между собой. Однако термин «связанный» может также означать, что, по меньшей мере, два элемента не находятся в непосредственном контакте между собой, но по-прежнему совместно работают или взаимодействуют между собой.

Следует подчеркнуть, что реферат изобретения предложен для обеспечения читателю возможности быстро выяснить сущность технического решения изобретения. Реферат представлен в предположении, что его не будут использовать для интерпретации или ограничения объема или смысла формулы изобретения. Кроме того, в вышеприведенном разделе Подробное описание можно обнаружить, что различные признаки сгруппированы в одном варианте осуществления с целью оптимизации раскрытия изобретения. Упомянутый способ раскрытия изобретения нельзя интерпретировать как отражение идеи, что заявленные варианты осуществления нуждаются в большем числе признаков, чем в явной форме перечислено в каждом пункте формулы изобретения. Напротив, как изложено в нижеприведенной формуле изобретения, предмет изобретения определяется меньшим числом, а не всеми признаками одного раскрытого варианта осуществления. Таким образом, нижеприведенная формула изобретения включена в раздел Подробное описание, при этом каждый пункт формулы изобретения занимает собственное место как отдельный вариант осуществления. В прилагаемой формуле изобретения термины «содержащий» («including») и «в котором» («in which») применены в качестве обычных английских эквивалентов соответствующих терминов «содержащий»(«comprising») и «в котором» («wherein»), соответственно. Кроме того, термины «первый», «второй», «третий» и т.д. применены просто в качестве обозначений и не предназначены для определения нумерационных требований к соответствующим им объектам.

Хотя описание предмета изобретения приведено на языке, характерном для структурных признаков и/или методологических правил действия, следует понимать, что предмет изобретения, определяемый в прилагаемой формуле изобретения, необязательно ограничен конкретными вышеописанными признаками или действиями. Более того, конкретные вышеописанные признаки и действия приведены в качестве примерных форм осуществления формулы изобретения.

Изобретение относится к структуре распределенного приложения, которая разбивает вычислительные задачи или рабочие нагрузки для прикладной программы между сервером и клиентом. Технический результат заключается в обеспечении шаблонов и возможности изменения компоновки существующего GUI-независимого объекта для применения логического преобразования для создания единственного экрана интерфейса GUI с новой компоновкой. Предложены методики автоматизированного преобразования объекта интерфейса пользователя и генерации кода. Аппаратура может содержать логическое устройство, выполненное с возможностью исполнения серверного приложения. Серверное приложение может содержать, наряду с другими элементами, интерпретирующий модуль исполняющей среды для формирования объекта, независимого от графического интерфейса пользователя, (GUI-независимого объекта), по набору полученных свойств пользовательского события. GUI-независимый объект подвергают обработке шаблона для создания нового GUI-независимого объекта, который может быть возвращен в клиентское приложение для визуализации. 3 н. и 7 з.п. ф-лы, 16 ил.

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

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

3. Компьютерно-реализуемый способ по п.1, в котором базовый шаблон содержит метаданные и содержимое для одного представления компоновки экрана интерфейса GUI, при этом шаблон экрана содержит метаданные и содержимое для индивидуально настроенного представления компоновки экрана интерфейса GUI, которая зависит от базового шаблона, и переопределяет данные базового шаблона.

4. Компьютерно-реализуемый способ по п.1, в котором экран с индивидуально настроенной новой компоновкой интерфейса GUI объединяет несколько экранов в один экран.

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

6. Машиночитаемый носитель данных, содержащий команды, которые при их исполнении обеспечивают возможность системе выполнять способ по любому из пп.1, 2, 3, 4 или 5.

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

8. Устройство по п.7, в котором интерпретирующий модуль исполняющей среды функционально связан с базой данных.

9. Устройство по п.7 или 8, в котором интерпретирующий модуль исполняющей среды дополнительно содержит интерпретатор скриптов, выполненный с возможностью исполнения скриптового кода в ответ на принятые свойства пользовательского события.

10. Устройство по п.7 или 8, в котором интерпретирующий модуль среды исполнения дополнительно содержит диспетчер файлов, выполненный с возможностью исполнения операций управления файлами в отношении файлов, хранящихся в базе данных.