СПОСОБЫ ДЛЯ АДАПТИРОВАНИЯ ИНТЕРПРЕТИРУЮЩЕГО ВРЕМЯ ВЫПОЛНЕНИЯ ПРИЛОЖЕНИЯ ДЛЯ МНОЖЕСТВЕННЫХ КЛИЕНТОВ Российский патент 2017 года по МПК G06F15/16 G06F3/48 G06F9/44 

ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ

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

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

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

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

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

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

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

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

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

[0008] Фиг. 1A иллюстрирует обычную настольную архитектуру приложений.

[0009] Фиг. 1B иллюстрирует обычную 2-ярусную архитектуру приложений.

[0010] Фиг. 1C иллюстрирует обычную 3-ярусную архитектуру приложений.

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

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

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

[0014] Фиг. 5 иллюстрирует первый логический поток операций расширенной n-ярусной клиент-серверной архитектуры в соответствии с одним вариантом осуществления.

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

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

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

[0018] Фиг. 8 иллюстрирует вариант осуществления вычислительной архитектуры, подходящей для расширенной n-ярусной клиент-серверной архитектуры, в соответствии с одним вариантом осуществления.

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

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

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

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

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

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

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

[0025] Фиг. 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.

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

[0027] В различных вариантах осуществления расширенная n-ярусная архитектура предоставляет структуру, которая разрешает миграцию 2-ярусной клиент-серверной прикладной архитектуры в 3-ярусную архитектуру приложений, которая использует «тонкого» клиента (клиентского терминала) для уровня отображения прикладной программы. В одном варианте осуществления, например, каждое устройство клиента может реализовывать тонкого клиента в форме web-клиента. Web-клиент обычно относится к приложению тонкого клиента, реализованному, используя web-технологии, такие как web-браузер, работающий на компьютере клиента, например. Он может также относиться к программным расширениям и приложениям помощника, которые расширяют браузер для поддержания службы с сайта или сервера. Любые ссылки в настоящем описании на web-клиента могут также относиться к функциональности web-браузера.

[0028] Фиг. 2 иллюстрирует клиент-серверную систему 200. В одном варианте осуществления клиент-серверная система 200 может содержать расширенную n-ярусную клиент-серверную систему. Расширенная n-ярусная клиент-серверная система может разделять прикладную программу на множественные ярусы, включающие в себя ярус отображения. Ярус отображения может быть реализован, используя способы, созданные для облегчения разделения и оптимизации визуализации GUI и пользовательских событий в прикладной программе, используя интерпретирующую при выполнении подсистему. Это позволяет адаптировать приложение интерпретирующей при выполнении подсистемы из 2-ярусной основанной на клиент-сервере архитектуры в хостированную 3-ярусную среду, в то же время уменьшая изменения, необходимые для приложения интерпретирующей при выполнении подсистемы.

[0029] Как описано ранее со ссылками на Фиг. 1A, множество приложений следуют 2-ярусной прикладной архитектуре, в которой приложение организовано в два взаимосвязанных компонента – сервер базы данных и приложение клиента. Сервер базы данных может хостировать данные системы и компании наряду с расширенной бизнес-логикой, которая разрешает ему обрабатывать некоторые более тяжелые операции, которые будут чрезвычайно времяемкими для выполнения в клиенте. Между тем приложение клиента может выполнять функции доставки UI, предоставления проверки достоверности данных ввода и визуализации отчетов, помимо других функций.

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

[0031] В одном варианте осуществления сервер 202 может содержать электронное устройство, реализующее приложение 210 сервера. Приложение 210 сервера может содержать любой тип серверного приложения, такого как коммерческое бизнес-приложение. Примеры коммерческих бизнес-приложений могут включать в себя, не ограничиваясь, бухгалтерскую программу, приложение планирования ресурсов предприятия (ERP), приложение администрирования отношений с клиентами (CRM), приложение администрирования поставок (SCM) и т.д. Эти коммерческие бизнес-приложения иногда называются приложениями "среднего яруса", так как они обычно выполняются серверами или массивом серверов в сетях коммерческого предприятия, а не устройствами клиента, такими как настольный компьютер. Конкретный пример может включать в себя Microsoft® Dynamics GP, разработанный Microsoft Corporation, Редмонд, Вашингтон. Microsoft Dynamics GP является коммерческим бухгалтерским приложением. Другой конкретный пример коммерческого бизнес-приложения может содержать Microsoft Dynamics® AX, разработанный Microsoft Corporation, Редмонд, Вашингтон. Microsoft Dynamics AX является коммерческим приложением ERP. Однако варианты осуществления не ограничены этими примерами.

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

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

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

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

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

[0037] Приложение 210 сервера может связываться с адаптерами 232, 242 клиента или отделять различные версии каждого, отдельно или одновременно. Сценарий для одновременной операции может включать в себя: когда пользователь запрашивает помощь, и администратор желает просмотреть вторую версию просмотра web-клиента пользователя.

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

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

[0040] Фиг. 3 иллюстрирует специфичную реализацию n-ярусной клиент-серверной системы 300. Клиент-серверная система 300 может содержать сервер 302 и клиент 304. Сервер 302 может представлять, например, сервер 202, описанный со ссылками на Фиг. 2. Клиент 304 может представлять, например, одного или двух клиентов 204, 206, описанных со ссылками на Фиг. 2.

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

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

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

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

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

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

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

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

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

[0050] Фиг. 4 иллюстрирует конкретную реализацию n-ярусной клиент-серверной системы 400. Клиент-серверная система 400 может содержать сервер 402 и клиент 404. Сервер 402 может представлять, например, серверы 202, 302, описанные со ссылками на ФИГ. 2, 3. Клиент 404 может представлять, например, одного или всех клиентов 204, 206, 304, описанных со ссылками на ФИГ. 2, 3.

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

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

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

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

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

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

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

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

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

[0060] Web-клиент 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 сервера.

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

[0062] Фиг. 5 иллюстрирует вариант осуществления логического потока 500. Логический поток 500 может иллюстрировать операции, выполненные в соответствии с одним или более вариантами осуществления. Например, логический поток 500 может иллюстрировать операции, выполненные web-клиентом 430 и/или приложением 410 сервера.

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

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

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

[0066] В логическом потоке 500 в тех случаях, когда запрашивается уведомление, адаптер клиента может посылать любые ожидаемые измененные свойства пользовательского события на серверное приложение на этапе 508. Например, адаптер 432 клиента может посылать измененные свойства 451 пользовательского события в сообщении 450 на приложение 410 сервера с помощью сети 250. В некоторых вариантах осуществления адаптер 432 клиента может посылать множественные наборы измененных свойств 451 пользовательского события для свойств пользовательского события в сообщении 450 для выполнения приложением 410 сервера на сервере 402. Этот посылаемый "пакет данных" может быть полезным разными способами, включающими в себя помощь приложению 410 сервера при распределении времени пользовательского события. Например, интерпретатор 414 скриптов может выполнять во времени различные скрипты (например, предварительно определенные скрипты, скрипты изменения, постскрипты и т.д.) для гарантии точной последовательности обновлений для приложения 410 сервера. Посылаемый пакет данных может также уменьшать служебные расходы связи посредством посылки меньшего количества сообщений 450 с помощью сети 250. Имеются также другие преимущества, и варианты осуществления не ограничиваются этим контекстом.

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

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

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

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

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

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

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

[0074] При совместном объединении результат может быть независимым от GUI объектом 616. Как показано в независимом от GUI объекте 616, Поле A является неизмененным от родовой версии метаданных, так как ни одно из его свойств или значений не было изменено в коллекции 614 свойств/значений. Поле Б показано без своей границы, так как свойство «граница» было установлено в значение «Ложь» в коллекции 614 свойств/значений. Текст в Поле С показан курсивом, так как свойство «курсив» было установлено в значение «Истина» в коллекции 614 свойств/значений. Объект 616 может затем быть визуализирован на клиенте 404 в web-клиенте 430 посредством подсистемы 438 визуализации адаптера 432 клиента.

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

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

[0077] Фиг. 8, иллюстрирует вариант осуществления примерной вычислительной архитектуры 800, подходящей для реализации различных вариантов осуществления, как описано ранее. Вычислительная архитектура 800 включает в себя различные обычные вычислительные элементы, такие как один или более процессоров, сопроцессоров, блоков памяти, наборов микросхем, контроллеров, периферийных устройств, интерфейсов, генераторов, устройств тактирования, видеокарт, звуковых карт, мультимедийных компонентов ввода/вывода (I/ О) и т.д. Варианты осуществления, однако, не ограничиваются реализацией вычислительной архитектуры 800.

[0078] Как показано на Фиг. 8, вычислительная архитектура 800 содержит блок 804 обработки, память 806 системы и системную шину 808. Блок 804 обработки может быть любым из различных коммерчески доступных процессоров. Двойные микропроцессоры и другая архитектура мультипроцессора может быть также использована в качестве блока 804 обработки. Системная шина 808 предоставляет интерфейс для системных компонентов, включающих в себя, но не ограниченных, память 806 системы для блока 804 обработки. Системная шина 808 может быть любой из нескольких типов шинных структур, которая может дополнительно подсоединяться к шине запоминающего устройства (с или без контроллера памяти), шине периферийных устройств и локальной шине, используя любое множество коммерчески доступных шинных архитектур.

[0079] Память 806 системы может включать в себя различные типы блоков памяти, такие как постоянное запоминающее устройство (ROM), оперативное запоминающее устройство (RAM), динамическое RAM (DRAM), DRAM с двойной скоростью передачи данных (DDRAM), синхронное DDRAM (SDRAM), статическое RAM (SRAM), программируемое ROM (PROM), стираемое программируемое ROM (EPROM), электрически стираемое программируемое ROM (EEPROM), флэш-память, память на полимере, такую как сегнетоэлектрическая память на полимере, память на аморфных полупроводниках, память на фазовых переходах или сегнетоэлектрическая, память на оксиде-кремния- нитриде-оксиде-кремния (SONOS), магнитные или оптические карты или любой другой тип носителей, подходящих для хранения информации. В иллюстрированном варианте осуществления, показанном на Фиг. 8, память 806 системы может включать в себя энергонезависимую память 810 и/или энергозависимую память 812. Базовая система ввода/вывода (BIOS) может быть сохранена в энергонезависимой памяти 810.

[0080] Компьютер 802 может включать в себя различные типы считываемых компьютером запоминающих носителей, включающих в себя внутренний жесткий диск (HDD) 814, накопитель 816 на гибких магнитных дисках (FDD) для считывания с или записи на сменный магнитный диск 818 и накопитель 820 на оптических дисках для считывания с или записи на сменный оптический диск 822 (например, CD-ROM или DVD). Жесткий диск 814, FDD 816 и накопитель 820 на оптических дисках могут быть соединены с системной шиной 808 посредством интерфейса 824 HDD, интерфейса 826 FDD и интерфейса 828 накопителя на оптических дисках соответственно. Интерфейс 824 HDD для реализаций внешнего накопителя может включать в себя по меньшей мере одну или обе технологии интерфейса универсальной последовательной шины (USB) и IEEE 1394.

[0081] Накопители и ассоциированные считываемые компьютером носители предоставляют энергозависимое и/или энергонезависимое хранение данных, структур данных, выполняемых компьютером команд и т.д. Например, множество программных модулей могут быть сохранены на накопителе и блоках 810, 812 памяти, включающих в себя операционную систему 830, одно или более приложений 832, другие программные модули 834 и программные данные 836. Одно или более приложений 832, другие программные модули 834 и программные данные 836 могут включать в себя, например, компоненты программного обеспечения для клиент-серверных систем 200, 300 и 400.

[0082] Пользователь может вводить команды и информацию в компьютер 802 с помощью одного или более проводного/беспроводного устройства ввода, например клавиатуры 838, и указывающего устройства, такого как мышь 840. Другие устройства ввода могут включать в себя микрофон, инфракрасное (IR) удаленное управление, джойстик, игровую панель, стилус, сенсорный экран и т.п. Эти и другие устройства ввода часто соединены с блоком 804 обработки с помощью интерфейса 842 устройства ввода, который соединен с системной шиной 808, но может быть соединен с другими интерфейсами, такими как параллельный порт, последовательный порт IEEE 1394, игровой порт, порт USB, интерфейс IR и т.д.

[0083] Один или более мониторов 844 или другой тип устройств отображения также соединен с системной шиной 808 с помощью интерфейса, такого как видео адаптер 846. В дополнение к монитору 844, компьютер обычно включает в себя другие периферийные устройства вывода, такие как динамики, принтеры и т.д. Один или более мониторов 845 могут также быть соединены с системной шиной 808 с помощью интерфейса 842 устройства ввода и/или концентратора, такого как концентратор 843 USB. Мониторы 845 могут содержать различные компоненты, такие как видеокамера, множество микрофонов, датчиков касания, датчиков движения, динамиков и т.д. Компоненты могут быть соединены с интерфейсом 842 устройств ввода с помощью концентратора 843 USB.

[0084] Компьютер 802 может работать в сетевой среде, используя логические соединения с помощью проводной и/или беспроводной связи с одним или более удаленными компьютерами, такими как удаленный компьютер 848. Удаленный компьютер 848 может быть рабочей станцией, серверным компьютером, маршрутизатором, персональным компьютером, портативным компьютером, основанным на микропроцессоре развлекательным устройством, одноранговым устройством или другим общим сетевым узлом и обычно включает в себя множество или все элементы, описанные относительно компьютера 802, хотя, для краткости, иллюстрируется только память/устройство 850 хранения данных. Изображенные логические соединения включают в себя проводную/беспроводную возможность соединения с локальной сетью (LAN) 852 и/или большими сетями, например глобальной сетью (WAN) 854. Такие сетевые среды LAN и WAN являются обыкновенными в офисах и компаниях и облегчают компьютерные сети всего предприятия, такие как интранет, все из которых могут соединяться с глобальной сетью связи, например Интернетом.

[0085] При использовании в сетевой среде LAN компьютер 802 соединяется с LAN 852 с помощью проводного и/или беспроводного сетевого интерфейса или адаптера 856. Адаптер 856 может облегчать проводную и/или беспроводную связь с LAN 852, которая может также включать в себя беспроводную точку доступа, расположенную на нем, для связи с беспроводными функциональными возможностями адаптера 856.

[0086] При использовании в сетевой среде WAN компьютер 802 может включать в себя модем 858 или соединяться с серверами связи по WAN 854, или иметь другое средство для установления связи по WAN 854, например, посредством Интернета. Модем 858, который может быть внутренним или внешним и проводным и/или беспроводным устройством, соединяется с системной шиной 808 с помощью интерфейса 842 устройства ввода. В сетевой среде программные модули, изображенные относительно компьютера 802 или их части, могут быть сохранены в удаленной памяти/устройстве 850 хранения данных. Должно быть оценено, что показанные сетевые связи являются примерными, и могут быть использованы другие средства установки линии связи между компьютерами.

[0087] Компьютер 802 работает для связи с проводными и беспроводными устройствами или объектами, используя семейство стандартов IEEE 802, например беспроводные устройства, оперативно расположенные в беспроводной сети (например, IEEE 802.11 способы радиомодуляции), например, принтер, сканер, персональный и/или портативный компьютер, персональный цифровой ассистент (PDA), спутник связи, любая часть оборудования или местоположение, ассоциированное с признаком, определенным беспроводным способом (например, киоск, газетный киоск, комната отдыха) и телефон. Это включает в себя по меньшей мере Wi-Fi (или Wi-Fi беспроводной интернет), WiMax и беспроводные технологии Bluetooth(TM). Таким образом, связь может быть предварительно определенной структурой как с обычной сетью или просто связью ad hoc между по меньшей мере двумя устройствами. Сети Wi-Fi используют радиотехнологии IEEE 802.11х(a, b, g и т.д.) для предоставления возможности безопасного, надежного, быстрого беспроводного соединения. Сеть Wi-Fi может быть использована для соединения компьютеров друг с другом, с Интернетом и для проводных сетей (которые используют связанные с IEEE 802.3 носители и функции).

[0088] Фиг. 9 иллюстрирует блок-схему примерной архитектуры 900 связи, подходящей для реализации различных вариантов осуществления, как описано ранее. Архитектура 900 связи включает в себя различные общие элементы связи, такие как передатчик, приемник, приемопередатчик, радиостанцию, сетевой интерфейс, процессор основной полосы частот, антенна, усилители, фильтры и т.д. Варианты осуществления, однако, не ограничиваются реализацией архитектуры 900 связи.

[0089] Как показано на Фиг. 9, архитектура 900 связи включает в себя один или более клиентов 902 и серверов 904. Клиенты 902 могут реализовывать web-клиенты 330. Серверы 904 могут реализовывать интерпретирующую при выполнении подсистему 312. Клиенты 902 и серверы 904 оперативно соединены с одним или более соответствующими хранилищами 908 данных клиента и хранилищами 910 данных сервера, которые могут быть использованы для локального хранения информации для соответствующих клиентов 902 и серверов 904, такой как cookie-файлы и/или ассоциированной контекстной информации.

[0090] Клиенты 902 и серверы 904 могут передавать информацию между друг другом, используя структуру 906 связи. Структура 906 связи может реализовывать любые известные способы связи, такие как способы, подходящие для использования с сетями с коммутацией пакетов (например, общественные сети, такие как Интернет, частные сети, такие как интранет предприятия, и т.д.), сетями с коммутацией каналов (например, общественная телефонная коммуникационная сеть) или комбинацией сетей с коммутацией пакетов и коммутацией каналов (с подходящими шлюзами и переводчиками). Клиенты 902 и серверы 904 могут включать в себя различные типы стандартных элементов связи, созданных для взаимодействия со структурой 906 связи, такой как один или более интерфейсов связи, сетевых интерфейсов, карт сетевого интерфейса (NIC), радио, беспроводных передатчиков/приемников (приемопередатчиков), проводных и/или беспроводных носителей, физических соединителей и т.д. Посредством примера, а не ограничения, коммуникационные носители включают в себя проводные носители и беспроводные носители. Примеры проводных носителей связи могут включать в себя провод, кабель, металлические выводы, печатные платы (PCB), объединительные платы, коммутируемую сеть устройств, полупроводниковое вещество, витую пару, коаксиальный кабель, волоконно-оптический кабель, распространяемый сигнал и т.д. Примеры беспроводных носителей могут включать в себя акустические, радиочастотного (RF) спектра, инфракрасные и другие беспроводные носители. Одна возможная связь между клиентом 902 и сервером 904 может быть в форме пакета данных, адаптированного для передачи между двумя или более компьютерными процессами. Пакет данных может включать в себя cookie-файлы и/или ассоциированную контекстную информацию, например.

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

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

[0093] Некоторые варианты осуществления могут быть описаны, используя выражение "один вариант осуществления" или "вариант осуществления" наряду с их производными. Эти термины обозначают, что конкретный признак, структура или характеристика, описанная вместе с вариантом осуществления, включены по меньшей мере в один вариант осуществления. Использования фразы "в одном варианте осуществления" в различных местах в описании не обязательно относится к одному и тому же варианту осуществления.

[0094] Некоторые варианты осуществления могут быть описаны, используя выражение "подсоединенный" и "соединенный" наряду с их производными. Эти термины не обязательно предназначены как синонимы друг для друга. Например, некоторые варианты осуществления могут быть описаны, используя термины "соединенный" и/или "подсоединенный" для указания, что два или более элементов находятся в прямом физическом или электронном контакте друг с другом. Термин "подсоединенный", однако, может также обозначать, что два или более элемента не находятся в прямом контакте друг с другом, но все еще совместно работают или взаимодействуют друг с другом.

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

[0096] Хотя заявленная сущность изобретения была описана на языке, специфичном для структурных признаков и/или методологических действий, должно быть понятно, что заявленная сущность изобретения, определенная в приложенной формуле изобретения, не обязательно ограничена специфичными признаками или действиями, описанными выше. Вместо этого специфичные признаки и действия, описанные выше, описаны в качестве в качестве примерных форм реализации формулы изобретения.

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

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

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

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

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

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

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

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

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

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

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

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

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

повторно подсоединяют новый экземпляр адаптера клиента к серверному приложению;

принимают от серверного приложения последнее известное состояние для всех независимых от GUI объектов; и

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

8. Машиночитаемый носитель информации, на котором сохранены машиноисполняемые инструкции, которые при их исполнении компьютерной системой предписывают компьютерной системе:

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

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

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

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

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

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

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

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

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

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

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

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

логические схемы; и

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

16. Устройство по п. 15, при этом обновленные свойства пользовательского события содержат метаданные объекта и совокупность свойство/значение, причем метаданные объекта содержат один или более элементов пользовательского интерфейса, а совокупность свойство/значение содержит один или более кортежей, каждый из которых содержит идентификатор для элемента пользовательского интерфейса, свойство для этого элемента пользовательского интерфейса и значение для этого свойства.

17. Устройство по п. 15, в котором адаптер клиента содержит диспетчер пользовательского интерфейса для управления клиентским пользовательским интерфейсом.

18. Устройство по п. 15, в котором адаптер клиента содержит подсистему визуализации для обновления отображаемого изображения.

19. Устройство по п. 15, в котором web-клиент выполнен с возможностью создавать новый экземпляр адаптера клиента, когда предыдущий экземпляр адаптера клиента и ассоциированное с ним отображаемое изображение, состоящее из одного или более зависимых от GUI объектов, повреждены.

20. Устройство по п. 19, в котором новый экземпляр адаптера клиента выполнен с возможностью повторно подсоединяться к серверному приложению, принимать от серверного приложения последнее известное состояние для всех независимых от GUI объектов и синхронизировать в новом экземпляре адаптера клиента последнее известное состояние для всех независимых от GUI объектов, принятых от серверного приложения.