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

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

 

Область техники, к которой относится изобретение

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

Общепринятые термины

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

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

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

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

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

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

События - действия пользователя или какие-либо иные изменения в компьютерной системе.

Конфигурация программного объекта - конкретный набор значений свойств этого объекта.

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

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

Интерфейс (программный) - определенный набор методов и свойств. Для поддержки программного интерфейса объект должен обладать всеми методами и свойствами, относящимися к данному интерфейсу.

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

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

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

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

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

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

Хеширование - разновидность шифрования без возможности расшифровки (однонаправленное шифрование).

Аутентификация пользователя - процедура, выполняемая при подключении пользователя к системе, когда пользователь с помощью условного имени и пароля удостоверяет свои пользовательские права.

Авторизация пользователя - процедура подтверждения полномочий пользователя в процессе работы информационной системы.

Термины, введенные автором изобретения

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

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

Уровень техники

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

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

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

Во многих информационных системах в качестве клиентской программы используется программы веб-браузеры, такие как Microsoft Internet Explorer, Mozilla или Opera, то есть эти информационные системы являются веб-приложениями. В отличие от веб-сайтов, предоставляющих пользователю заранее предопределенный набор веб-страниц, веб-приложение работает интерактивно и предоставляет веб-страницы, созданные динамически в соответствии с запросом пользователя. Сильной стороной веб-приложений является универсальность клиентской программы. Веб-браузер устанавливается на компьютере-клиенте один раз, часто при установке операционной системы. Затем он может использоваться в качестве клиентской программы в самых различных веб-приложениях. Это исключает необходимость установки специализированных клиентских программ для каждого отдельного веб-приложения. В веб-приложении логика работы информационной системы и способ представления информации клиенту целиком определяется серверной стороной. Поэтому достаточно частые изменения в этой логике и способах представления информации не требуют каких-либо изменений в клиентской программе.

Однако возможности веб-приложений ограничены. Это связано с довольно бедными возможностями пользовательского интерфейса, предоставляемого веб-браузером. В последнее время предпринимаются попытки усовершенствования пользовательского интерфейса веб-приложений на основе спецификаций XForms [XForms 1.0 (W3C Recommendation) http://www.w3.org/TR/xforms/] и WebForms 2.0 [WebForms 2.0 (Working Draft) http://whatwg.org/specs/web-forms/current-work/]. Тем не менее, новые спецификации не позволяют преодолеть разрыв, отделяющий пользовательский интерфейс веб-приложений от значительно более совершенного графического пользовательского интерфейса, предоставляемого системами Windows, MacOS, XWindow, Java и др. Поэтому в случаях, когда распределенная информационная система нуждается в развитом графическом пользовательском интерфейсе, разработчики вынуждены создавать специализированные клиентские программы, «родные» для данной клиентской платформы, то есть базирующиеся на интерфейсах программирования приложений конкретной клиентской платформы. В этом случае для каждой информационной системы требуется своя клиентская программа, каждое изменение в логике работы информационной системы или способах представления информации пользователю требует обновления клиентской программы (ее переустановки на клиентском компьютере). Пересылка и переустановка новых версий клиенткой программы вызывает дополнительную нагрузку на линии связи, создает значительные неудобства для пользователей, приводит к дополнительным финансовым затратам.

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

Известны способы предоставления развитого графического пользовательского интерфейса веб-приложения за счет внедрения в веб-страницы компонентов ActiveX или Java апплетов [X.Дейтел, П.Дейтел, Т.Нието. Как программировать для Интернет & WWW. M. "Бином", 2002, 1184 с.]. Однако эти способы не решают поставленной задачи, так как соответствующие внедряемые компоненты не являются универсальными (для каждого веб-приложения требуются специализированные компоненты) и требуют обновления при изменении логики работы информационной системы или изменения способа представления информации. То же самое относиться и к новой технологии Java Web Start[Java Web Start Technology, http://java.sun.com/products/javawebstart/], которая предназначена для усовершенствования Java апплетов.

Известны варианты реализации информационной системы клиент-сервер в архитектуре «тонкого клиента» [US 2002130900; US 2003135825]. Согласно [US 2002130900; US 2003135825] объекты пользовательского интерфейса создаются динамически, по описаниям на языке структурной разметки XML, полученным с сервера. Это позволяет уменьшить нагрузку на линии связи за счет универсального характера клиентской программы. Однако дополнительная нагрузка на линии связи из-за обработки клиентских событий на сервере сводит на нет это преимущество.

Наиболее близким аналогом данного изобретения является [WO 2004019160]. В [WO 2004019160] предлагается программные объекты пользовательского интерфейса на клиентском компьютере создавать динамически на основании полученных с сервера описаний на каком-либо языке структурной разметки (XML, XSL, DHTML, XHTML, HTML). Индивидуализация поведения программных объектов пользовательского интерфейса достигается с помощью сценариев на языке JavaScript. Считается, что такие системы могут обладать свойством расширяемости, то есть в систему по мере необходимости могут быть добавлены объекты новых типов. Однако для работы сценария обычно необходимо задание объектной модели - набора заранее предопределенных объектных типов (классов, в терминологии объектно-ориентированного программирования), что противоречит принципу расширяемости. Эти предложения пока не получили распространения, возможно, именно из-за указанного противоречия и сложности реализации универсального механизма поддержки сценариев.

Раскрытие изобретения

В изобретении поставленная задача решается путем использования на клиентской стороне универсальной системы динамически создаваемых, самодостаточных программных объектов и организации работы информационной системы клиент-сервер в соответствии с определенным алгоритмом. Так же, как в [US 2002130900; US 2003135825; WO 2004019160] в данном изобретении программные объекты на клиентском компьютере создаются динамически по их описаниям, полученным с сервера, но в данном изобретении объекты пользовательского интерфейса не встраиваются в веб-браузер, а функционируют в составе универсальной клиентской программы. В отличие от [US 2002130900; US 2003135825] в данном изобретении для функционирования пользовательского интерфейса не требуется обращения к серверу. В отличие от [WO 2004019160] в данном изобретении для функционирования системы не требуется поддержки механизма сценариев. Использование в данном изобретении системы самодостаточных программных объектов исключает сложности реализации универсального механизма поддержки сценариев. Для осуществления данного изобретения не имеет принципиального значения используемый формат описаний самодостаточных объектов.

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

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

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

Фиг.1 поясняет функционирование системы самодостаточных объектов в случае запроса на модификацию и получение данных.

На фиг.2 представлена блок-схема алгоритма при запросе на модификацию и получение данных.

Фиг.3 поясняет функционирование системы самодостаточных объектов при запросе нового контейнера. Для простоты на этой схеме не показан механизм кэширования.

На фиг.4 представлена блок-схема алгоритма при запросе нового контейнера без механизма кэширования.

Фиг.5 поясняет механизм кэширования при запросе нового контейнера.

На фиг.6 представлена блок-схема алгоритма кэширования при запросе нового контейнера.

Фиг.7 демонстрирует пример оконной формы, предназначенной для проведения платежей по кредитным картам.

На фиг.8 представлена блок-схема алгоритма при проведении платежей по кредитным картам.

На фиг.9 представлена блок-схема алгоритма при полном или выборочном шифровании запроса.

На фиг.10 представлена блок-схема алгоритма при полном или выборочном расшифровывании отклика.

На фиг.11 представлена блок-схема алгоритма запуска универсальной клиентской программы.

Осуществление изобретения

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

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

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

- Получатели - надписи, строки ввода, текстовые области, списки, таблицы, диаграммы и другие объекты, способные получать и, возможно, отображать данные, полученные с сервера.

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

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

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

Некоторые самодостаточные объекты могут относиться сразу к нескольким категориям, например одновременно быть запросчиками и получателями.

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

Перечислим минимальный достаточный набор методов и свойств интерфейсов соответствующих перечисленных категорий самодостаточных объектов.

Интерфейс Инициатор:

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

Интерфейс Посредник:

- свойство Контейнер - определяет контейнер, который будет участвовать в формировании запроса;

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

- свойство ИмяКонтейнера - определяет, какой именно контейнер требуется (если запрашивается новый) или для какого контейнера запрашиваются данные;

- свойство АдресСервера - содержит сетевой адрес сервера, реализующего информационную систему;

- метод Пошел - приводит посредника в действие.

Интерфейс Запросчик:

- метод ПолучитьЗапрос - возвращает часть запроса, соответствующую данному запросчику.

Интерфейс Получатель:

- метод УстановитьДанные - передает соответствующие данные конкретному получателю.

Интерфейс Контейнер:

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

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

Интерфейс Декоратор не требуется.

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

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

Проследим по фиг.1 взаимодействие клиента и сервера в случае запроса на модификацию и получение данных (блок-схема фиг.2).

Условные обозначения: 1 - сервер, 2 - клиент, 3 - клиентская программа, 4 - стадия формирования запроса, 5 - стадия обработки отклика.

Последовательность действий:

- Пользователь 6 приводит в действие Инициатор 7 (кнопку, пункт меню и т.п.) (блок 21).

- Инициатор 7 вызывает для Посредника 8 метод Пошел (блок 22).

- Посредник 8 для Контейнера 9 вызывает метод СформироватьЗапрос (блок 23).

- Контейнер 9 опрашивает относящиеся к нему самодостаточные объекты-запросчики (цикл, блоки 24-26), вызывая для каждого из них метод ПолучитьЗапрос (блок 24), формирует запрос из частей, соответствующих запросчикам (блок 25), и возвращает сформированный запрос Посреднику 8 (блок 27). (Блок 26 проверяет условие - все ли запросчики обработаны?)

- Посредник 8 пересылает запрос Серверной Программе 10 по адресу АдресСервера (блок 28).

- Серверная Программа 10 модифицирует данные в Базе Данных 12 (блок 29), запрашивает и получат данные из Базы Данных 12 (блок 30).

- Серверная Программа 10 приводит данные к нужному формату (блок 31) и пересылает их Посреднику 8 (блок 32).

- Посредник 8 передает полученные данные в уже существующий Контейнер 13, вызывая метод РапределитьДанные (контейнер 13 может совпадать с исходным контейнером 9) (блок 33).

- Контейнер 13 распределяет полученные данные между относящимися к нему самодостаточными объектами-получателями (цикл, блоки 34-35), вызывая метод УстановитьДанные для каждого получателя (блок 34). (Блок 35 проверяет условие - все ли получатели обработаны?)

По фиг.3 проследим взаимодействия клиента и сервера при запросе нового контейнера (без кэширования) (блок-схема фиг.4).

Последовательность действий:

- Пользователь 6 приводит в действие Инициатор 7 (кнопку, пункт меню и т.п.) (блок 41).

- Инициатор 7 вызывает для Посредника 8 метод Пошел (блок 42).

- Посредник 8 для Контейнера 9 вызывает метод СформироватьЗапрос (блок 43).

- Контейнер 9 опрашивает относящиеся к нему самодостаточные объекты-запросчики (цикл, блоки 44-46), вызывает для каждого из них метод ПолучитьЗапрос (блок 44), формируя запрос из частей, соответствующих запросчикам (блок 45), и возвращает сформированный запрос Посреднику 8 (блок 47). (Блок 46 проверяет условие - все ли запросчики обработаны)

- Посредник 8 пересылает запрос Серверной Программе 10 по адресу АдресСервера (блок 48).

- Серверная Программа 10 находит и считывает описание нового контейнера, находящееся на Серверном Машиночитаемом Носителе Данных 11 (блок 49).

- Серверная программа 10 пересылает описание нового контейнера Посреднику 8 (блок 50).

- Посредник 8 по полученному описанию создает Новый Контейнер 14 (блок 51).

- Посредник 8 направляет повторный запрос на сервер, теперь для получения данных для Нового Контейнера 14 (блок 52).

- Серверная Программа 10 запрашивает и получает данные из Базы Данных 12 (блок 53).

- Серверная Программа 10 приводит данные к нужному формату и пересылает их Посреднику 8 (блок 54).

- Посредник 8 передает полученные данные в уже существующий Новый Контейнер 14, вызывая метод РаспределитьДанные (блок 55).

- Контейнер 14 распределяет полученные данные между относящимися к нему самодостаточными объектами-получателями (цикл, блоки 56 -57), вызывая метод УстановитьДанные для каждого получателя (блок 56). (Блок 57 проверяет условие - все ли получатели обработаны?)

Проследим по фиг.5 функционирование механизма кэширования при запросе нового контейнера (блок-схема фиг.6).

Вначале, вплоть до получения Посредником 8 от Контейнера 9 сформированного запроса, выполняются действия в соответствии с фиг.3 (блоки 41-47 фиг.4). Далее выполняются следующие действия:

- Посредник 8 ищет на Клиентском Машиночитаемом Носителе Данных 15 описание нового контейнера и версию этого описания (блок 61). Если описание и его версия присутствуют на клиентском компьютере (блок 62), Посредник 8 включает в запрос версию описания (блок 63).

- Посредник 8 пересылает запрос Серверной Программе 10 по адресу АдресСервера (блок 64).

- Серверная Программа 10 находит и считывает описание нового контейнера и версию описания, находящиеся на Серверном Машиночитаемом Носителе Данных 11 (блок 65).

- Серверная Программа 10 сравнивает версии описаний с клиентского 15 и серверного 11 машиночитаемых носителей данных (блок 66). Если версии описаний совпадают, то Серверная Программа включает в отклик соответствующий признак (блок 67). В этом случае описание и его версия на клиентский компьютер не пересылаются. Если версии не совпадают или версия описания в запросе отсутствует, Серверная Программа включает в отклик описание и его версию (блок 68).

- Серверная программа 10 пересылает отклик Посреднику 8 (блок 69).

- Посредник 8 анализирует отклик. Если признак совпадения версий отсутствует (блок 70), то Посредник сохраняет полученные описание и его версию на клиентском Машиночитаемом Носителе Данных 15, при необходимости, заменяя имеющиеся описание и его версию (блок 71). В противном случае используется уже имеющееся описание (блок 72).

- Посредник 8 по имеющемуся описанию (возможно, только что полученному) создает Новый Контейнер 14 (блок 73).

- Далее выполняются действия в соответствие с фиг.3 для получения данных для нового контейнера (блоки 52-57 фиг.4).

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

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

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

Фиг.1-6 иллюстрируют взаимодействия внутри системы самодостаточных объектов. Мы рассмотрели два типа запросов. Алгоритмы выполнения запросов других типов не имеют принципиальных отличий от рассмотренных алгоритмов. Функционирование системы в полной мере использует режим "запрос-отклик", характерный для любой системы клиент-сервер. Именно функционирование информационной системы в этом режиме позволяет выстроить универсальные последовательности действий. Важно отметить, что рассмотренные последовательности действий могут выполняться без привлечения каких-либо обработчиков событий, в том числе основанных на сценариях.

Для успешного участия в выполнении запроса и получения отклика достаточно правильно сконфигурировать систему самодостаточных объектов, то есть правильно установить значения их свойств. В частности, в случае запроса, показанного на фиг.1, у объектов должен быть правильно установлен ряд свойств:

- у Инициатора 7 свойство Посредник должно указывать на Посредника 8, участвующего в запросе;

- у Посредника 8 свойство Контейнер должно указывать на Контейнер 9, формирующий запрос; свойство ТипЗапроса должно соответствовать типу запроса; свойство ИмяКонтейнера должно соответствовать имени Контейнера 14, для которого запрашиваются данные; свойство АдресСервера должно содержать соответствующие данные;

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

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

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

Рассмотрим теперь взаимодействие системы самодостаточных объектов с пользователем. Характер этого взаимодействия так же, как их взаимодействия внутри системы, полностью определяется конфигурацией самодостаточных объектов. Самодостаточные объекты воспринимаются пользователем информационной системы как элементы графического пользовательского интерфейса. По своей сути они должны предоставлять развитый графический пользовательский интерфейс, характерный для клиентских платформ Windows, MacOS, XWindow или Java. Поэтому они создаются на базе интерфейсов программирования приложений конкретной клиентской платформы. Адекватное поведение объектов пользовательского интерфейса предполагает:

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

- предупреждение пользователя о его неадекватных действиях;

- взаимную согласованность объектов.

Покажем, каким образом все эти функции можно реализовать без использования обработчиков событий, исключительно путем настройки конфигурации самодостаточных объектов. Рассмотрим пример. На фиг.7 схематически показана оконная форма 101, предназначенная для проведения платежей по кредитным картам (для упрощения показаны не все необходимые поля). Выпадающий список 102 представляет собой специализированный объект, содержащий список поддерживаемых кредитных карт, например: VISA, American Express, Золотая Корона и т.д. Поля ввода 103-107 предназначены для ввода соответствующих цифровых и буквенных данных: 103 - номера кредитной карты, 104 и 105 - месяца и года годности кредитной карты, 106 - суммы платежа и 107 - имени держателя карты. Объекты 102-107 являются запросчиками. Кнопки 108 и 109 инициируют операции передачи запроса на сервер и закрытия оконной формы соответственно. На фигуре не показан посредник, который присутствует в контейнере 101, но для пользователя является невидимым. У посредника свойство Контейнер должно указывать на оконную форму 101. У кнопки 108 свойство Посредник должно указывать на существующего посредника.

Покажем, как могут быть реализованы ограничения ввода информации. Для полей ввода ограничения можно связать со свойствами ТипСодержимого и МаксимальнаяДлина. Свойство МаксимальнаяДлина определяет максимально возможное количество введенных символов. Свойство ТипСодержимого определяет, какие символы могут вводиться в строку. Так для строк ввода 103-105 свойство ТипСодержимого должно быть установлено в значение Целый. Этот тип содержимого допускает ввод только цифровых символов. Для строки ввода 106 свойство ТипСодержимого должно быть установлено в значение Денежный. Этот тип содержимого допускает ввод только цифровых символов и символа десятичного разделителя (точки или запятой, в зависимости от региональных настроек). Аналогично настраиваются и другие поля ввода. В процессе ввода символов, объект - строка ввода проверяет соответствие вводимых символов значению свойства ТипСодержимого и игнорирует недопустимые символы. Важно, что контроль ввода выполняется самим объектом, а не внешним по отношению к объекту обработчиком события.

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

- Кнопка 108 приводит в действие посредник (вызывает для посредника метод Пошел) (блок 81).

- Посредник вызывает для контейнера 101 (на которого указывает свойство Контейнер) метод СформироватьЗапрос (блок 82).

- Контейнер 101 перебирает относящиеся к нему самодостаточные объекты-запросчики 102-107 (цикл, блоки 83-86), вызывая для каждого из них метод ПолучитьЗапрос (блок 83). (Блок 86 проверяет все ли запросчики обработаны.)

- При вызове метода ПолучитьЗапрос для выпадающего списка 102 происходит проверка адекватности действий пользователя (блок 84). В данном случае выбрал ли пользователь тип кредитной карты. Если пользователь не выбрал тип кредитной карты, что является неадекватным действием, работа программы прерывается, выпадающий список открывает для пользователя окно сообщения (блок 85) с текстом «Не выбран тип кредитной карты».

- При вызове метода ПолучитьЗапрос для каждой из строк ввода 103-107, каждая строка самостоятельно проверяет адекватность действий пользователя (блок 84). Для строк ввода это означает проверку, заполнено ли это поле. Если пользователь не заполнил строку ввода 103, что является неадекватным действием, работа программы прерывается, строка ввода 103 открывает для пользователя окно сообщения (блок 85) с текстом «Не заполнено поле «Номер кредитной карты». (Текст «Номер кредитной карты» должен содержаться в свойстве ИмяПоля строки ввода 103.)

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

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

Покажем, каким образом можно реализовать взаимно согласованное поведение самодостаточных объектов. В рассматриваемом примере (фиг.7) количество цифр в номере кредитной карты (строка ввода 103) зависит от типа кредитной карты, выбранного в выпадающем списке 102. Так, например, номер кредитной карты VISA может состоять из 13 или 16 цифр, номер кредитной карты American Express из 15 цифр, номер карты Dinners Club из 14 цифр и т.д. Кроме того, корректные номера кредитных карт подчиняются правилам, специфичным для каждого конкретного типа карты. Поэтому именно объекты 102 и 103 должны действовать согласованно. Для решения этой задачи строка ввода номера кредитной карты должна обладать свойством СписокКредитныхКарт, указывающим на список 102. В этом случае, в процессе ввода, допустимое количество введенных цифр может быть согласованно с типом кредитной карты, выбранным в списке 102, а при вызове метода ПолучитьЗапрос для строки ввода 103 можно по соответствующему алгоритму осуществить проверку соответствия введенного номера типу кредитной карты. В случае несоответствия введенного номера типу кредитной карты пользователь может быть предупрежден соответствующим сообщением. Важно, что эта работа выполняется самим самодостаточным объектом строка ввода, а не обработчиком события.

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

Рассмотренные выше последовательности действий составляют, по сути, основу для оригинального протокола работы информационной системы клиент-сервер, который может быть сформулирован после их определенной формализации. Данный протокол может выполняться поверх известных сетевых протоколов, таких как TCP/IP, HTTP, HTTPS, SOAP [X.Дейтел, П.Дейтел, Т.Нието. Как программировать для Интернет & WWW. M. "Бином", 2002, 1184 с.] и других, например протоколов передачи данных в сетях мобильной связи. Выбор базового сетевого протокола не имеет принципиального значения и сказывается только на особенностях реализации. Выбор протокола более высокого уровня (например, HTTP по сравнению с TCP/IP или SOAP по сравнению с HTTP) позволяет упростить процесс реализации. Напротив выбор протокола низкого уровня позволит сделать передаваемые пакеты данных более компактньми и уменьшить объем данных, пересылаемых по линиям связи.

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

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

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

- Если используется незащищенное соединение, то передавать пароль по линии связи в открытом или даже хешированном виде нельзя. В этом случае аутентификация потребует выполнения двух запросов (второй уровень) и может быть проведена в два приема по типу дайджест-аутентификации или по протоколу Kerberos [Джоел Скембрей, Майк Шема Секреты хакеров. Безопасность Web-приложений - готовые решения, М. «Вильяме», 2003, 383 с.].

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

Если в качестве базового сетевого протокола используется протокол без шифрования данных, например TCP/IP или HTTP, то защита данных, в виде полного или выборочного шифрования запросов и откликов, может быть встроена непосредственно в рассматриваемую систему. Для этого необходимо, чтобы интерфейсы Запросчик, Получатель и Контейнер включали следующие свойства:

Интерфейс Запросчик:

- свойство-флаг ШифроватьЗапрос устанавливается, если часть запроса, соответствующую данному запросчику, следует зашифровать.

Интерфейс Получатель:

- свойство-флаг РасшифроватьОтклик устанавливается, если часть отклика, соответствующую данному получателю, следует расшифровать.

Интерфейс Контейнер:

- свойство-флаг ШифроватьПолныйЗапрос устанавливается, если весь запрос следует зашифровать

- свойство-флаг РасшифроватьВесьОтклик устанавливается, если весь отклик следует расшифровать.

Алгоритмы шифрования могут быть реализованы в виде динамически загружаемых библиотек. Для полного и/или частичного шифрования запросов и расшифровывания откликов могут использоваться различные алгоритмы. Таким образом, одновременно может быть использовано до 4 различных алгоритмов шифрования.

Покажем, как можно выполнить полное и/или частичное шифрование при формировании запроса (блок-схема фиг.9). При вызове метода СформироватьЗапрос (блок 121) контейнер опрашивает относящиеся к нему самодостаточные объекты-запросчики (цикл 122-126), вызывая для каждого из них метод ПолучитьЗапрос (блок 122). Если у запросчика установлено свойство ШифроватьЗапрос (блок 123), контейнер шифрует эту часть запроса (блок 124) с помощью динамически загружаемой библиотеки и включает ее в полный запрос (блок 125) в зашифрованном виде. Блок 126 проверяет, все ли запросчики обработаны. Если у контейнера установлено свойство ШифроватьПолныйЗапрос (блок 127), то сформированный запрос дополнительно шифруется (блок 128) перед отправкой на сервер (блок 129).

Покажем, как можно выполнить полное и/или частичное расшифровывание при получении отклика с сервера (блок-схема фиг.10). При вызове метода РапределитьДанные (блок 141), если у контейнера установлено свойство РасшифроватьВесьОтклик (блок 142), то контейнер расшифровывает отклик, полученный с сервера (блок 143) с помощью динамически загружаемой библиотеки. Контейнер распределяет полученные данные между, относящимися к нему самодостаточными объектами-получателями (цикл, блоки 144-148), вызывая метод УстановитьДанные для каждого получателя (блок 144). Если у конкретного получателя установлено свойство РасшифроватьОтклик (блок 145), контейнер расшифровывает данные (блок 146) с помощью динамически загружаемой библиотеки, предназначенные для этого получателя, перед вызовом метода УстановитьДанные (блок 147). Блок 148 проверяет, все ли получатели обработаны.

Ключи шифрования могут быть получены с сервера при аутентификации пользователя по протоколу Kerberos [Джоел Скембрей, Майк Шема, Секреты хакеров. Безопасность Web-приложений - готовые решения, М. «Вильяме», 2003, 383 с.]. Эти ключи действуют в течение одного рабочего сеанса.

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

Рассмотрим теперь работу клиентского компьютера под управлением универсальной клиентской программы, основанной на системе самодостаточных программных объектов.

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

Для начала работы конкретного приложения клиентской программе достаточно иметь следующие данные:

- сетевой адрес сервера приложения;

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

- имя первого контейнера, то есть контейнера, запрашиваемого непосредственно после аутентификации пользователя;

- список динамически загружаемых библиотек с самодостаточными объектами, дополняющими систему (при необходимости);

- список динамически загружаемых библиотек с алгоритмами для полного или частичного шифрования запросов и откликов (при необходимости).

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

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

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

- для выполнения запросов аутентификации создается и конфигурируется объект-посредник (блок 164);

- если способ аутентификации пользователя требует введения имени пользователя и пароля (первый и второй уровни) (блок 165), то создается, а затем отображается на экране монитора специальная оконная форма, содержащая строки ввода имени и пароля и кнопку ввода в систему (блок 166);

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

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

- в случае успешной аутентификации (блок 169) существующий посредник запрашивает по известному имени первый создаваемый контейнер (первую оконную форму) (блок 170);

- посредник создает и конфигурирует по полученному описанию первую оконную форму (блок 171);

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

- работа пользователя с информационной системой завершается после закрытия им первой оконной формы (блок 173).

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

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

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

2. Информационная система по п.1, отличающаяся использованием в качестве базового, сетевого протокола TCP/IP.

3. Информационная система по п.1, отличающаяся использованием в качестве базовых, сетевых протоколов HTTP и HTTPS.

4. Информационная система по п.1, отличающаяся использованием в качестве базового, протокола SOAP поверх сетевых протоколов HTTP и HTTPS.

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

6. Информационная система по п.1, отличающаяся применением аутентификации пользователей по типу дайджест-аутентификации.

7. Информационная система по п.1, отличающаяся применением аутентификации пользователей по протоколу Kerberos.

8. Информационная система по п.1, отличающаяся применением механизма кэширования описаний самодостаточных объектов.

9. Информационная система по п.1, отличающаяся применением полного и/или выборочного шифрования запросов и откликов с использованием сеансовых ключей.

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

11. Информационная система по п.1, отличающаяся тем, что в качестве линий связи используются сети радио и мобильной связи, а в качестве клиентов используются сотовые телефоны.

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