Автоматизированное преобразование объекта интерфейса пользователя и генерация кода

Автоматизированное преобразование объекта интерфейса пользователя и генерация кода

Иллюстрации

Показать все

Реферат

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

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

Одной формой архитектуры клиент-сервер является многозвенная архитектура, часто называемая 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) элемента интерфейса пользователя, свойство (например, границу, шрифт, размер шрифта, цвет шрифта, фон, цвет фона, стиль, выравнивание по правому краю, в