Способ и система для создания ит-ориентированных серверных сетевых приложений

Изобретение относится к способу управления объектами приложений. Технический результат заключается в уменьшении нагрузки на канал передачи данных. Управляют множеством различных приложений на сервере. Принимают от клиентского звена, имеющего браузер, множество запросов на множество объектов приложений из указанного множества различных приложений. Пересылают базовый статический код указанному клиенту, который выполняет указанный базовый статический код. Пересылают от указанного сервера множество команд, каждая из которых указывает состояние отдельного объекта приложения из множества объектов приложения, указанному клиенту для воспроизведения указанным базовым статическим кодом, имеющимся в клиенте, каждого объекта приложения согласно соответствующему состоянию с помощью указанного браузера. Принимают от указанного клиента множество клиентских событий, каждое из которых относится к отдельному объекту приложения указанного множества объектов приложения. Идентифицируют, для каждого из указанного множества клиентских событий, соответствующее приложение из указанного множества различных приложений и обновляют каждое состояние посредством обработки указанного множества клиентских событий на указанном сервере в соответствии с упомянутой идентификацией. 3 н. и 19 з.п. ф-лы, 3 ил.

 

Область техники

Настоящее изобретение относится к веб-приложениям. Более конкретно, настоящее изобретение относится к способу и системе для создания ИТ (Информационные Технологии) - ориентированных веб-приложений, предоставляемых по сети передачи данных, такой как Интернет.

Определения, сокращения и аббревиатуры

В данном описании используются следующие определения.

Событие: действие, выполненное пользователем в приложении.

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

Уникальное событие: событие, которое в итоге отправляется серверу.

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

Клиент или клиентское звено - это терминал пользователя (например, веб-страница), подключенный к серверу.

Элемент управления: отображаемый компонент приложения (например, кнопка, поле и т.п.). Каждый элемент управления может выполнять определенные операции (например, получение данных, вводимых с клавиатуры, нажатие и т.д.)

Контейнер: окно, которое включает элементы управления.

Разделитель: боковая панель (горизонтальная или вертикальная), аналогичная элементу управления, которая помещается между двумя закрепленными/привязанными элементами управления и которая позволяет изменять соотношение размеров (ширину или высоту) одного из этих элементов управления за счет другого посредством ее перетаскивания.

Выделенное (специализированное) ядро

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

- передачу и прием данных любого вида на сервер и от сервера;

- активацию XSL (язык для форматирования документа XML: например, указывает, как данные, описываемые в документе XML, должны быть представлены на веб-странице) преобразований (указывают, как документ XML должен быть преобразован в другую структуру данных, которая затем может быть представлена путем сопровождения таблицы стилей XSL) или любой другой технологии формирования макета на уровне представления;

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

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

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

Дерево объектов приложения: дерево объектов, включающее объекты приложения в виде структуры иерархического дерева, представляющего структуру GUI (Graphical User Interface - графический интерфейс пользователя).

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

Окно главной формы: первое окно, которое видит пользователь, когда получает доступ к URL, который обрабатывается по данной технологии. Это окно эквивалентно главному окну, которое открывается при запуске настольного приложения.

Временная метка клиента: отметка времени для объекта на клиентской стороне, отражающая время последнего обновления.

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

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

Уникальное накопленное событие: новое событие, которое замещает любое событие, имеющее такой же ID, поскольку старое событие устарело.

Команды обновления: набор элементов XML (Extensible Markup Language - расширяемый язык разметки), которые исполняет браузер, чтобы синхронизироваться с деревом объектов приложения и контрольным состоянием сервера.

Структура окна: набор элементов XML, описывающих структуру текущего окна приложения. Структура окна используется для обновления состояния клиентского звена (прорисованный в данный момент UI) в соответствии с состоянием серверного звена (текущее состояние UI на сервере).

Шаблоны XSLT: набор XSLT (Extensible Stylesheet Language Transformations - преобразования расширяемого языка таблиц стилей), который описывает преобразования, которые необходимо выполнить с данными, чтобы сформировать отображаемые элементы управления в клиентском звене (например, веб-браузере).

Данные на основе XML: данные XML, которые используются клиентом для хранения состояния интерфейса приложения. Состояние интерфейса приложения содержит свойства каждого элемента управления UI и включает всю информацию, необходимую клиенту для синхронизации состояния своих элементов управления в соответствии с состоянием сервера, например цвет или размер элемента управления, отображаемый им текст и т.д. Это обеспечивает клиентское звено возможностью переформировывать любую часть UI посредством использования XSLT (преобразование шаблонов) для данных на основе XML.

Предпосылки создания изобретения

В настоящее время HTML (HyperText Markup Language - язык гипертекстовой разметки) является международным стандартным языком, который освобожден от авторского права и является доступным для всех разработчиков, а также поддерживается во всех средах программирования. Способность предлагать ссылки для навигации и возможность поддержки мультимедиа (звук, изображение, анимация и т.п.) явилось причиной того, что мировое сообщество приняло HTML как основной промышленный стандарт. Также в последнее время был представлен язык DHTML (Dynamic HTML - динамический HTML). DHTML - это совокупность технологий, используемых вместе для создания интерактивных и анимированных веб-сайтов с использованием комбинации статического языка разметки (такого как HTML), языка сценариев клиентских приложений (такого как JavaScript™), языка описания представлений (CSS; Cascading Style Sheets - каскадные таблицы стилей) и объектной модели документа (интерфейс программирования). Таким образом, DHTML позволил в большей степени обеспечить интерактивность с пользователями Интернета. Проникновение Интернета во все области жизни и быстрое распространение Интернета среди пользователей, наряду с растущим спросом производственных и коммерческих кругов на использование Интернета в качестве средства связи со своими пользователями, повлекло за собой потребность в более динамичных и более сложных удаленных клиент-серверных приложениях для Интернета. Это привело к внедрению ASP (Application Service Provider - провайдер прикладных услуг), РНР (Hypertext Preprocessor - гипертекстовый препроцессор) и других языков/сред для веб-приложений, которые предоставляют новые полезные функции, такие как динамически создаваемые страницы, которые прежде были статическими. Эти новые среды внесли способность выставлять и принимать данные посредством стандартных HTML страниц.

Недостаточно высокая клиент-серверная производительность веб-ориентированных ИТ приложений в настоящее время не может удовлетворить растущие требования все более сложных ИТ приложений. Несмотря на значительное развитие Интернета, который становится основным связующим звеном при использовании ИТ, основные принципы, обеспечивающие это использование, остались такими же, как и два десятилетия назад. В наши дни ASP.NET (Active Server Pages - активные серверные страницы) и JSP (Java^® Server Pages - серверные страницы Java) предлагают наилучшую среду разработки на «стороне сервера». На стороне клиента страницы HTML включают сценарии, которые вызывают серверные страницы, т.е. страницы полностью реконструируются после каждого действия на серверной стороне, что приводит к ограниченной низкой производительности. Кроме того, использование веб-приложений, которые значительно зависят от сценариев, стало нормой у веб-разработчиков. Требования веб-приложений становятся все более и более похожими на требования приложений для настольных компьютеров. Множество функциональных возможностей, которые прежде поддерживались только "настольными приложениями" (desktop applications), становятся неотъемлемой частью веб-приложений. Это требует высоких расходов на пропускную способность, т.е. веб-ресурсов для транспортировки. Сценарии на клиентской стороне становятся все более и более сложными, что делает веб-приложения трудными для разработки и обслуживания. Кроме того, проблемы качества работы таких приложений являются обычными. Легко разрушить содержание, поскольку сценарии не обеспечивают ограничений на доступ к коду и предлагают скудные принципы объектно-ориентированного программирования, если они вообще есть.

Также одной из основных проблем остаются вопросы безопасности существующих веб-ориентированных технологий, поскольку сценарии выполняются браузером клиента (например, Microsoft® Internet Explorer). Использование языков сценариев, встраиваемых в браузер пользователя, сделало веб-приложения уязвимыми для вредоносных манипуляций, поскольку страницы, которые служат источником данных для веб-приложений, трудно защитить. Большая часть данных обрабатывается браузером на стороне пользователя (а не на стороне сервера) и по этой причине раскрывается больше данных, чем требуется.

Помимо этого технологии ASP.NET и JSP уже устарели, поскольку они не способны нормально справляться с современными требованиями ИТ. Несмотря на то, что введены более мощные возможности программирования, такие как новые инфраструктурные средства программирования, новое моделирование и возможность многократного использования (многократное использование - это возможность создать компоненты один раз и позже использовать их несколько раз), основные принципы до сих пор остались прежними и приводят к указанным выше проблемам (т.е. производительность, взаимодействие с пользователем, безопасность, сложность разработки и обслуживания). Концепция таких сред на базе страниц оказывается неудовлетворительной для разработки веб-приложений, поскольку на стороне сервера отсутствует поддержка открывания окон или взаимодействия между фреймами (так как большая часть кода управления окнами должна быть написана на клиентских языках сценариев, распределяющих бизнес-логику на несколько языков и местоположений). Существует ограниченная поддержка частичного обновления интерфейса пользователя, которая требует от разработчика подробного управления частичным обновлением и снижает производительность процесса разработки. Кроме того, пропускная способность существующих систем ИТ ограничена, и они не способны удовлетворить современным требованиям, для которых необходимо больше ресурсов для обработки информации. Это ведет к потерям дорогостоящего времени пользователей. Сложные действия ведут к медленному выполнению сценариев браузером, причем каждое действие вызывает отдельную страницу, которая полностью воссоздается сервером и полностью формируется браузером. В настоящее время только разработчик один решает, какое содержание будут иметь данные, передаваемые между клиентской стороной и серверной стороной. Этот факт делает данные несовместимыми и нестандартными, т.е. данные могут включать данные представления, деловые данные, все виды маркеров доступа и другие типы данных. Более того, данные могут иметь любой формат, например обычный текст, XML или любой другой формат. Некоторые разработчики, а также некоторые проекты могут использовать индивидуальные и сильно различающиеся протоколы данных и форматов, отправляемых серверу и принимаемых от сервера. Разработчик должен владеть множеством языков Интернета, которые требуют серьезного обучения, и, следовательно, квалифицированных специалистов очень трудно найти.

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

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

Вид страницы создается посредством использования трех инструментальных средств.

1. Таблицы HTML (которые могут включать веб-текст и использоваться также для размещения любых элементов HTML).

2. Стили управления потоками данных, такие как описание макета CSS (Cascading Style Sheets - каскадные таблицы стилей).

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

Все вышесказанное описывает сложную рабочую среду проектирования веб-приложений. Также указаны недостатки и ограничения при использовании таких приложений.

В наиболее близком аналоге (публикация 2003/0200254 А1) задачи приложения разделяются между сервером и клиентом. Клиент, использующий такое приложение, должен инсталлировать сервисную программу (JAVA приложение). Это означает, что некоторые задачи по обработке выполняются на стороне клиента. Это вынуждает пользователя устанавливать только авторизованные компьютеры и определенные операционную систему и веб-браузер. Также эти приложения хуже адаптируются при обновлении операционной системы и веб-браузера. Другим недостатком клиентской стороны, выполняющей некоторые задачи приложения по обработке, является способ осуществления связи. Пакеты данных, которые возможно содержат важную информацию, необходимо передавать от клиентской стороны серверу и обратно. Такая связь является далеко не идеальной из-за объема данных (полосы пропускания) и затрат времени. Также сохраняются угрозы безопасности, поскольку важная информация доступна клиентской стороне, которая соединяется с глобальной сетью.

Приложение «Remote Desktop Connection» (удаленный рабочий стол) компании Микрософт - это программа, которая позволяет использовать приложения на серверах/компьютерах через сеть передачи данных. Приложение фактически запускается на сервере/компьютере, а пользователь, используя другой компьютер / терминал, подключенный к сети, может управлять этим приложением. Здесь используется передача изображения экрана в форме растрового изображения приложения пользователю/клиенту. Клиент посылает обратно события, связанные с клавиатурой и мышью. Данные, передаваемые сервером, представляют собой снимок экрана (растровое изображение) приложения на сервере, отображающий точное изображение экрана, сформированное на сервере. Чтобы получить "гладкое" изображение на стороне пользователя, растровые изображения передаются от сервера с высокой частотой. Пакеты данных являются большими, и скорость передачи высокая. Это приводит к массовой активности в сети и к потреблению большого объема сетевых ресурсов (пропускной способности). Такое приложение требует использования одинаковой операционной системы на сервере и клиенте. Также на клиентской стороне требуется установка апплета для поддержки этого приложения.

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

Целью настоящего изобретения является создание системы и способа предоставления ИТ-ориентированных серверных веб-приложений.

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

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

Еще одной целью настоящего изобретения является создание способа и системы, в которых не используются языки сценариев клиента или другие веб-языки, такие как JavaScript.

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

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

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

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

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

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

Целью настоящего изобретения является создание способа и системы для обеспечения разработчиков ИТ-ориентированного серверного веб-приложения новой средой разработки, которая является совместимой со средой разработки Microsoft^®.

Другие цели и преимущества настоящего изобретения станут очевидными из последующего описания.

Сущность изобретения

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

Клиентская сторона может представлять собой любой браузер, работающий под управлением любой операционной системы. Уровень представления не зависит от кода выделенного ядра и может представлять собой DHTML, WinForms^® (оболочка для создания клиентских приложений Windows, использующая общеязыковую среду исполнения; приложения WinForms^® могут быть написаны на любом языке, который поддерживает общеязыковая среда исполнения), Microsoft^®Silverlight™ (подключаемый к браузеру модуль, позволяющий выполнять разработку веб-приложений) или другую среду, которая поддерживается любым другим уровнем представления, который способен передавать и принимать коды XML.

Выделенное ядро может быть кодом, который изменяется между разными поддерживаемыми уровнями представления. Обмен данными между сервером и клиентской стороной производится только посредством XML.

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

Краткое описание чертежей

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

на фиг.1 показана схема инициализации клиентской стороны для системы, предлагаемой настоящим изобретением;

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

на фиг.3 показана схема архитектуры системы для обеспечения ИТ-ориентированных серверных веб-приложений в соответствии с предпочтительным вариантом осуществления настоящего изобретения.

Подробное описание предпочтительных вариантов осуществления изобретения

Система согласно настоящему изобретению делает шаг вперед в области клиент-серверных ИТ-приложений как в вопросе разработки таких приложений, так и в использовании такой системы. Новшество в сфере разработки заключается в использовании любого программного обеспечения для объектно-ориентированного программирования (язык программирования высокого уровня) с целью разработки веб-приложений. Для разработчиков это полностью устраняет необходимость использовать общепринятые средства программирования веба/Интернета (например, HTML, XML, CSS и т.п.). Характер этой системы делает разработку веб-приложения доступной для любого программиста, а не только для тех, кто специализируется на языках проектирования веба/Интернета. Другим очевидным преимуществом настоящего изобретения является использование одного языка программирования вместо нескольких. Разработка макета (layout) при использовании данной системы является значительно более простой, чем при обычном способе существующего уровня техники. Отсутствует необходимость описывать размеры и свойства окон и элементов управления в символах/числах, а используется только способ «перетащить и оставить», аналогично тому, как это реализовано в некоторых средах разработки настольных приложений, таких как "Visual Studio". Также здесь реализуется способ разработки макета - закрепление и привязка (описывается в разделе «Предпосылки создания изобретения»), который делает разработку и модификацию макета более простой и удобной для пользователя.

Новшества и преимущества при использовании системы настоящего изобретения также распространяются на сторону клиента (пользователя) и способ связи клиент-сервер.

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

Далее описываются дополнительные аспекты способа связи в системе настоящего изобретения. Связь между сервером и браузером осуществляется с использованием одного URL (Uniform Res ource Locator; универсальный указатель ресурса - адрес веб-сайта) посредством использования главного окна приложения. Приложение может включать множество окон, но тем не менее связь с сервером осуществляется через один адрес.

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

ИТ приложение, которое разрабатывается с использованием системы настоящего изобретения, может быть подготовлено на компьютере программиста и затем опубликовано в сети (инсталлировано на сервере) или может программироваться прямо на сервере через сеть, т.е. путем удаленного программирования. В последнем способе программирования используется такой же способ связи, как клиент-сервер, который используется при применении системы настоящего изобретения. В этом случае программист является пользователем на клиентской стороне, а приложением на стороне сервера являются средства проектирования для создания приложения ИТ. Последующие иллюстрации относятся к обоим случаям: удаленный разработчик ИТ приложения, использующий систему настоящего изобретения, и пользователь самого ИТ приложения. В последующем описании приложение означает либо приложение ИТ, либо средства проектирования, а пользователь означает либо пользователя ИТ приложения, либо удаленного программиста.

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

На фиг.2 показана стандартная процедура взаимодействия между сервером 200 и клиентской стороной 300. После регистрации любое взаимодействие между пользователем и приложением выполняется следующим образом: на стороне клиента 300 действия пользователя на экране (например, щелчки мышью, ввод текста с клавиатуры или любой другой ввод данных пользователем) преобразуются в события. Каждому событию присваивается уникальный идентификатор ID и временная метка. События организуются в очередь на стороне 300 клиента. Когда происходит критическое событие, вся очередь передается на сервер 200. Когда сервер 200 получает данные, он преобразует события в действия приложения и подготавливает пакет данных для отправки обратно клиентской стороне 300. Пакет данных включает только необходимую информацию, которая требуется клиенту для обновления содержания экрана и отражения результата действий приложения. Эти операции повторяются до тех пор, пока пользователь подключен к приложению.

Существуют случаи, когда пользователь не производит никаких действий (например, щелчков мышью, ввода текста с клавиатуры и т.д.), но события все равно будут запускаться на сервере. Это происходит вследствие срабатываний таймеров, которые периодически производит инфраструктура (например, "Keep-connected" - сохранение подключения, которое является событием, запускаемым через постоянный конфигурируемый интервал времени, и которое синхронизирует клиента и сервер во время простоя), или в результате запроса разработчика на асинхронные операции (т.е. асинхронный таймер, которым управляет разработчик для вызова асинхронных событий, таких как индикаторы выполнения или периодические обновления, автоматически запускаемые клиентским компьютером).

На фиг.3 схематично показана система 100 для обеспечения ИТ-ориентированных серверных веб-приложений в соответствии с предпочтительным вариантом осуществления настоящего изобретения. Система 100 включает три звена: звено 105 приложения, серверное звено 115 и клиентское звено 300. Клиентское звено 300 взаимодействует с серверным звеном 115, которое в свою очередь взаимодействует со звеном 105 приложения. Взаимодействие между клиентским звеном 300 и серверным звеном 115 осуществляется посредством событий, которые организуются в очередь и передаются от браузера 135 на сервер 116 приложения в форме XML (Extensible Markup Language - расширяемый язык разметки). С другой стороны, взаимодействие между северным звеном 115 и клиентским звеном 300 осуществляется посредством команд обновления, которые посылаются сервером 116 приложения браузеру 135 в форме XML.

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

Серверное звено 115, которое также включает сервер 116 приложения, выполняет следующие функции:

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

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

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

- возвращение команд обновления из браузера 135 в сервер 116 приложения с использованием временной метки, пересылаемой от серверного звена при последнем ответе сервера (обеспечивается в клиентском звене 300) на сервер 116 приложения (обеспечивается в серверном звене 115);

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

Клиентское звено 300 также включает следующие программные компоненты:

- браузер 135 (например, Mozilla Firefox^® или Microsoft^® Internet Explorer) для навигации по сети передачи данных, такой как Интернет;

- сценарии 127 управления браузером, которые являются сценариями, загружаемыми при первом обращении, и используются как «базовая оболочка». «Базовая оболочка» означает, что сценарии клиентского звена загружаются один раз и используются для всех целей в отличие от других оболочек, в которых каждое состояние приложения/управления требует загрузки специального сценария. Такой сценарий «базовой оболочки» используется для связи с сервером 116 приложения и обновления клиентского звена 300 посредством команд обновления, принятых от указанного сервера 116 приложения. Сценарий «базовой оболочки» позволяет клиентскому звену ввести в действие команды обновления, которые могут включать, как указано выше, частичные/полные инструкции, определяющие, что необходимо изменить или заново воспроизвести в клиентском звене. Сценарий «базовой оболочки» также позволяет выполнять последующую передачу информации на сервер о том, что происходит в клиентском звене (клиентские события), например пользователь 130 щелкает/дважды щелкает мышью, изменяет текст, перемещает мышь и т.п.;

- документ 126 XSL, который генерируется на сервере 116 приложения и используется для преобразования команд обновления, которые посылаются сервером 116 приложения браузеру 135, в код HTML, который замещает существующий код HTML. Это выполняется посредством XSL преобразования данных обновления на основе XML, которые обеспечивают преобразование заново обновленных свойств в отображаемые элементы управления;

- документ 128 XML статуса интерфейса, который хранит состояние интерфейса и используется для воспроизведения пошагового обновления и сохранения состояния интерфейса. При хранении документа XML с данными о свойствах в клиентском звене можно выполнять пошаговые обновления, поскольку серверное звено может передавать только необходимые данные на каждом шаге, посредством обновления документа 128 XML статуса интерфейса и заново воспроизводить только те части, которые требуется воспроизвести;

- документ 136 CSS, который генерируется в серверном звене и используется как общее оформление (такое как цвет фона, размеры границ, цвет границы, стиль макета и т.д.) для всех воспроизводимых элементов HTML (данные + преобразованный код XSLT).

События клиента (например, щелчки мышью, двойные щелчки, перемещения мыши и т.п.) организуются в очередь в сценариях 127 управления браузера. Клиентские события подразделяются на три основные категории:

- накопленные события: такие события организуются посредством сценариев 127 управления браузера в очередь 129 событий клиента;

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

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

При первоначальном запросе URL (который представляет собой URL, вводимый в веб-браузере с целью перехода в точку входа приложения), который работает под управлением сервера 116 приложения, указанный сервер 116 приложения производит поиск внутри конфигурации 108 приложения, чтобы определить отображение на класс объектов приложения (для данного URL). После обнаружения отображаемого класса объектов приложения в программном компоненте указанной конфигурации 108 приложения этот класс инициализируется, чтобы установить корневой объект дерева 106 объектов приложения (это означает, что корневой объект инициализируется, чтобы создать точку входа приложения и показать ее в клиентском звене). Затем команда полного обновления возвращается от сервера 116 приложения в клиентское звено 300, что позволяет указанному клиентскому звену 300 инициализировать клиентский интерфейс. Инициализация - это процесс создания новых объектов для всех отображаемых в настоящий момент элементов управления в определенном состоянии и присвоения им требуемых исходных свойств. С этого момента связь между клиентским звеном 300 и сервером 116 приложения осуществляется посредством событий и команд обновления, за исключением того, когда вызывается операция обновления (может быть вызвана нажатием кнопки обновления в браузере или изменением некоторого основного свойства приложения, такого как язык), которая приводит к тому, что серверное звено 115 передает еще раз команды полного обновления.

Когда критическое событие запускает передачу очереди событий, сценарии 127 управления браузера посылают очередь действий серверу 116 приложения (находится в очереди 129 событий клиента) совместно с уникальной клиентской меткой, например временной меткой, которая является числовым значением, отображающим время последнего обновления клиентского звена 135. Затем сервер 116 приложения в серверном звене 115 принимает очередь событий и временную метку клиента. После этого сервер обрабатывает очередь событий от конца к началу в порядке возникновения событий. Каждое событие в очереди событий имеет значение источника, которое представляет собой идентификатор ID объекта приложения, с которым связано данное событие. Такой идентификатор ID объекта приложения, полученный из текущего события, используется при поиске по индексу 107 объектов приложения для получения объектной ссылки на объект приложения, к которому относится данное событие. Объект текущего события посылается методу объекта приложения (методу, который является обработчиком события объекта для данного типа событий), который преобразует событие объекта в вызов стандартного события (вызов стандартного события - это способ сервера передавать события между объектами в отличие от нестандартных событий, которые являются событиями, передаваемыми от клиентского звена серверному звену приложения в соответствии с настоящим изобретением). Затем объект приложения в зависимости от типа (типа элемента управления, т.е. кнопка, форма, окно списка и т.п.) и поведения (способ реагирования на каждое событие данного конкретного объекта приложения), которое этот элемент использует, посылает стандартные кодовые события, которые могут быть использованы разработчиком программного кода. Стандартное кодовое событие принимается и является хорошо известным алгоритмом отправки сообщений между объектами, написанными посредством такой же технологии (т.е. С#, Java и др.), например объект, который посылает сообщение с целью информировать свой контейнерный объект о некотором изменении, которое произошло в его данных, в отличие от нестандартного события, которое представлено в настоящем изобретении. Нестандартное событие проходит между клиентским звеном и сервером приложения посредством алгоритма настоящего изобретения, когда, например, отображаемый клиентом элемент HTML посылает событие, сообщающее о том, что по нему произведен щелчок; а когда это событие фактически передается объекту, который должен обработать его в серверном звене, оно преобразуется в стандартное кодовое событие посредством алгоритма настоящего изобретения.

После того, как все события отправлены из клиентского звена серверу 115 приложения, указанный сервер 115 приложения вызывает корневой объект приложения, который является корнем дерева 106 объектов приложения, для формирования команд обновления, которые должны быть выполнены в клиентском звене 300 для синхронизации с деревом 106 объектов приложения. Для создания команд обновления временная метка клиента посылается корневому объекту приложения в дереве 106 объектов приложения, который в свою очередь запускает действие рекурсивного формирования, которое вызывает каждый объект приложения в указанном дереве 106 объектов приложения для проверки его временной метки, чтобы определить, требуется ли генерировать одну или более команду обновления. Объект приложения может хранить одну или более временных меток, и таким образом он может генерировать различные команды обновления для обновления компонентов, когда это необходимо. Эта мультивременная метка объекта приложения в настоящее время используется для команд частичного обновления (например, обновления только атрибутов объекта приложения, таких как цвет фона, содержащиеся данные и т.п.). Команды частичного обновления используются для того, чтобы сделать процесс обновления настолько эффективным, насколько возможно, в отношении числа элементов, которые необходимо переформировать, и их сложности.

Команды обновления, созданные деревом 106 объектов приложения, посылаются серверу 116 приложения в серверном звене 115, который в свою очередь посылает указанные команды обновления в виде документа XML в клиентское звено 300. Сценарии 127 управления браузера принимают команды обновления и обновляют документ 128 XML статуса интерфейса. Затем обновляемые элементы по одному преобразуются в представление в коде HTML для отображения на дисплее 131 с использованием документа 126 XSL. HTML представление создается путем XSL преобразования документа 128 XML статуса интерфейса с использованием соответствующего шаблона XSL (для того элемента, который представляет собой элемент управления).

Управление открытыми окнами приложений осуществляется аналогично всем другим объектам приложения, но команды обновления, которые возвращаются из серверного звена 115 для открывания окна, или команда обновления, которая сохраняет окно открытым, также включают указание на структуру XML окна (структуры элементов XML могут либо являться объектом приложения, содержащимся в окне, так что этот элемент будет включаться, либо самой структурой окна в виде корневого узла XML), которая представляет собой структуру текущего окна (например, главное окно, модальное диалоговое окно или немодальное диалоговое окно, размеры, положение и т.д.). Когда сценарии 127 управления браузера получают структуру XML открытых окон, он сканирует (циклы по открытым в настоящий момент окнам) указанные окна, чтобы определить, нужно ли закрыть одно из них, и сканирует структуру окон, чтобы определить, нужно ли открыть новое окно. Управление содержанием окон осуществляется аналогично управлению содержанием главного окна (главное окно - это окно браузера, которое отображает исходный URL при запуске, тогда как другие окна открываются поверх главного окна во время работы приложения) посредством управления идентификатором ID объекта приложения для обновления, который является уникальным, так что его можно определить при поиске по окнам, что означает, что ID объекта приложения не может повторяться в других окнах, даже если данный объект приложения содержится в совершенно другом контейнере. Таким способом объект может быть обнаружен в XML однозначно, независимо от содержащего его окна.

В соответствии с вариантом осуществления настоящего изобретения используются описания макета обычных настольных приложений, которые описывают атрибуты закрепления и привязки к элементам макета. Макет с закреплением легче обслуживать, чем таблицы HTML или абсолютное позиционирование, которое используется в обычных веб-приложениях. В конечном счете на выходе остается HTML, но программист описывает только те атрибуты, которые относятся к закреплению или привязке к объекту приложения. Объекты приложения, которые поддерживают закрепление, имеют свойство закрепления, которое является перечислителем «слева», «сверху», «справа», «снизу» и «заполнение». Эти перечислители описывают поведение макета объекта приложения:

- определение закрепления «сверху» приводит к тому, что объект приложения появляется в самой верхней позиции, в соответствии с определением высоты, а ширина объекта приложения будет максимально возможной;

- определение закрепления «снизу» приводит к тому, что объект приложения появляется в самой нижней позиции, в соответствии с определением высоты, а ширина объекта приложения будет максимально возможной;

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

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

- определение закрепления «заполнение» приводит к тому, что объект приложения заполняет оставшуюся клиентскую область. Любые объекты приложения, которые будут определены после заполняющего объекта приложения, не будут отображаться совсем, так как объект приложения с закреплением «заполнение» уже занял все оставшееся место.

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

Когда пользователь переходит на URL, который управляется сервером 116 приложения, он отображается на класс корневого объекта приложения (отображение производится так, что приложение будет иметь точку входа, указывающую, что конкретный объект приложения представляет собой первый экран для отображения), причем этот класс инициализируется и действует как корневой объект для всех других объектов приложения дерева 106 объектов приложения. Программирование приложения производится посредством событий приложения с целью изменения текущего статуса (например, программирование кода, который формируется, когда происходит событие, связанное со щелчком мышью, выбором пункта из списка и т.д.) и структуры (например, программирование кода, который вызывает появление/ исчезновение элементов управления, изменение размеров/стиля/состояния элементов управления, открывание окна и т.д.) дерева объектов приложения, а сервер отражает эти изменения в браузере клиента посредством команд обновления, которые используются для синхронизации текущего состояния интерфейса с состоянием дерева объектов приложения. Управление окнами веб-приложения также производится с использованием дерева объектов приложения. Для открывания окна программисту требуется создать новый экземпляр объекта, который наследует класс окна. Вызов функции «показать окно» (которая является функцией, которая дает серверу команду показать экземпляр окна) этого объекта помечает данный объект окна как видимый, и в следующих командах обновления это окно будет добавлено в структуру окон, что сообщает браузеру, что на сервере было создано окно и требуется открыть новое окно и воспроизвести его содержание. При вызове функции «скрыть окно», которая является функцией, которая дает серверу команду скрыть существующее окно и посылает клиенту новую команду обновления, которая не включает структуры этого окна, указывается, что данное окно должно быть закрыто. Браузер всегда сравнивает открытые в настоящий момент окна со списком структуры окон в команде обновления; при этом возможны 3 случая.

1. Окно существует как в команде обновления, так и в документе 128 XML статуса интерфейса, тогда окно должно оставаться открытым, поскольку оно является видимым как в состоянии серверного звена, так и в состоянии клиентского звена.

2. Окно существует в команде обновления, но не существует в документе 128 XML статуса интерфейса, тогда должно быть открыто новое окно с указанным содержимым внутри структуры нового окна, поскольку оно является видимым в состоянии серверного звена, но невидимым в состоянии клиентского звена.

3. Окно не существует в команде обновления, но существует в документе 128 XML статуса интерфейса, тогда существующее окно должно быть закрыто, поскольку оно является невидимым в состоянии серверного звена, но видимым в состоянии клиентского звена.

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

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

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

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

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

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

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

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

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

5. Способ по п.1, в котором указанная команда не содержит логический сценарий, относящийся к указанному объекту приложения.

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

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

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

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

10. Способ по п.1, в котором управление включает инициализацию указанного множества приложений в ответ на запрос от указанного клиента.

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

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

13. Система по п.12, в которой сервер управляет логическим сценарием и обрабатывает логический сценарий для каждого указанного объекта приложения.

14. Система по п.13, в которой логический сценарий не обрабатывается указанным клиентом.

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

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

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

18. Способ по п.15, в котором указанный по меньшей мере один объект приложения представляет собой конвертированное настольное приложение.

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

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

21. Способ по п.20, в котором указанный базовый статический код не инсталлирован в указанную память.

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