Способы для адаптирования интерпретирующего время выполнения приложения для множественных клиентов

Способы для адаптирования интерпретирующего время выполнения приложения для множественных клиентов

Иллюстрации

Показать все

Реферат

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

[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 сервера может гарантировать, что вводы приложения и состояния прил