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

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

Иллюстрации

Показать все

Реферат

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

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

Предшествующий уровень техники

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

Для некоторых клиентских приложений трафик клиент-сервер является смесью распространяемых в Web расширений авторизации и управления версиями (Web Distributed Authoring and Versioning) (WebDAV) к протоколу передачи гипертекстовых файлов (HTTP) и других различных схем (например, на основании упрощенных пар "имя - значения" в запросах POST HTTP). Использование множества протоколов для доступа к данным в этих известных системах усложняет реализацию и способствует малой надежности при эксплуатации. Эти системы предшествующего уровня техники также используют непоследовательную и недостаточную схему для запросов. Формат имя-значение, такой как используемый в некоторых известных системах, является очень ограниченным и легко не поддерживает данные со строгим контролем типов или более сложные структуры или массивы. Кроме того, так как формат имя-значение требует (символа) конца строки в качестве разделителя для пар имя-значение, все данные для конкретной пары имя-значение должны быть закодированы без символа конца строки перед передачей и затем декодированы после приема. Эти дополнительные этапы в некоторых существующих системах замедляют обработку и увеличивают сложность. Еще одна другая проблема с некоторыми существующими клиентскими web-приложениями состоит в том, что код на стороне сервера, обеспечивающий различные функциональные возможности клиентскому приложению, является хаотическим и дезорганизованным. Добавление новых обработчиков запросов к коду на стороне сервера существующих систем является затруднительным.

Соответственно, требуется усовершенствованная система для связи клиент-сервер, чтобы разрешить один или более из этих и других недостатков.

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

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

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

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

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

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

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

Альтернативно, изобретение может содержать различные другие способы и устройства.

Другие признаки должны быть частично очевидны и частично указаны ниже.

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

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

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

Фиг. 3 является примерной блок-схемой, иллюстрирующей модули в серверном компоненте.

Фиг. 4 является примерной блок-схемой, иллюстрирующей примерный набор классов обработчика событий.

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

Приложение A описывает примерные события и параметры в пространстве имен электронной почты согласно изобретению.

Соответствующие ссылочные символы указывают соответствующие части на чертежах.

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

В варианте осуществления изобретение включает в себя серверное приложение, компонент, процесс, или подобное, доставляющее данные к развернутому сервером клиентскому приложению, компоненту, процессу, или подобному в ответ на запрос данных от клиентского приложения, например, как проиллюстрировано на фиг. 1. На серверном компоненте 102 код или подпрограмма для ответа на запрос данных, такого как запрос 103 данных, разделяется на обработчики событий (например, множество обработчиков 104 событий) или подобные. Обработчики 104 событий логически организованы в одном варианте осуществления в пространство имен. В частности, изобретение включает в себя построение запроса, такого как запрос 103 данных, который содержит информацию о пространстве имен и обработчике событий для выполнения, а также параметры для этого обработчика. Изобретение дополнительно включает в себя инфраструктуру в сервере 102, которая позволяет разработчикам реализовать обработчики запросов, которые доставляют ответы на запросы данных.

Один пример изобретения вовлекает представление календаря в распределенном приложении управления персональной информацией. Представление календаря показывает список назначений на данный день. Сервер 102 обновляет (восстанавливает) это представление в календаре посредством запроса базы данных, чтобы извлечь назначения в заданном временном диапазоне. Извлеченные назначения затем выдаются в клиенте (например, клиентском компоненте 108) в правых позициях в зависимости от начального времени и продолжительности каждого из назначений. В предшествующих системах такая операция восстановления достигалась клиентским компонентом 108, запрашивающим данные, которые должны быть возвращены в формате расширяемого языка разметки (XML), используя распространяемые в Web расширения авторизации и управления версиями (WebDAV) для протокола передачи гипертекстовых файлов (HTTP), используя преобразование расширяемого определения схемы (XSD), чтобы сформировать HTML из XML данных, и представить HTML пользователю. Такие системы являются сложными и трудными для поддержания.

Однако, согласно изобретению обновление календаря достигается клиентским компонентом 108, посылающим форматированный запрос данных (например, запрос 103 данных) и принимающим поток кода (например, JavaScript), определяющего календарные данные. Календарные данные частично воспроизводятся (визуализируются) в сервере 102. Клиентский компонент 108 выполняет код и формирует HTML-разметку, используя сценарий. Нагрузка на клиентский компонент 108 уменьшается, так как большинство данных календаря и информация отображения предварительно вычисляются в сервере 102. В другом примере изобретения сервер 102 обновляет представление почты приложения PIM посредством возврата HTML, который был визуализирован в сервере 102. Изобретение не ограничено возвращением данных в любом конкретном формате. Скорее, изобретение возвращает данные в любой форме, продиктованной клиентским компонентом 108, такой как HTML, XML, текст, полезные данные JavaScript, или подобной.

Обращаясь снова к фиг. 1, примерная блок-схема иллюстрирует серверный компонент, процесс, или подобное, такое как серверный компонент 102, обменивающийся данными через сеть (например, Интернет) с одним или более клиентскими компонентами 108, процессами, или подобными, такими как клиентский компонент №1 - клиентский компонент № N. Система согласно фиг. 1 включает в себя один или более считываемых компьютером носителей, таких как область 106 памяти. Область 106 памяти хранит множество обработчиков 104 событий, каждый имеющий пространство имен, ассоциированное с ним. Каждый из множества обработчиков 104 событий дополнительно имеет один или более параметров, ассоциированных с ним. Структура данных, представляющая отформатированный запрос 103 данных, также сохранена на считываемом компьютером носителе. На фиг. 1 запрос данных показан посылаемым от клиентского компонента 108 к серверному компоненту 102. Структура данных, представляющая запрос 103 данных, включает в себя поле пространства имен, хранящее значение пространства имен, представляющее это пространство имен. Структура данных дополнительно включает в себя поле обработчика событий, хранящее значение обработчика событий, соответствующее одному из множества обработчиков 104 событий, сохраненных в области 106 памяти, которая ассоциирована с пространством имен, представленным значением пространства имен в поле пространства имен. Структура данных дополнительно включает в себя поле параметров, хранящее по меньшей мере одно значение параметра, соответствующее параметру, ассоциированному с обработчиком событий, представленным значением обработчика событий в поле обработчика событий.

В примере согласно фиг. 1 клиентский компонент 108 является первым процессом, а серверный компонент 102 является вторым процессом. Первый процесс является распределенным клиентским приложением или, иначе, развернутым посредством второго процесса, чтобы обеспечить некоторые или все функциональные возможности серверного компонента 102. Например, первый процесс может быть развернутым сервером клиентским приложением, таким как развернутый сервером клиент управления персональной информацией, и серверный компонент 102 может быть сервером управления персональной информацией. Однако изобретение не ограничено отношениями клиент-сервер между первым процессом и вторым процессом. Например, отношения между первым процессом и вторым процессом могут быть одноранговыми.

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

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

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

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

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

В одном варианте осуществления изобретение реализуется, используя HTTP-запросы с глаголом POST (отправить почтовое сообщение) или GET (получить). Запрос включает в себя следующую информацию: пространство имен (например, обозначенный в строке запроса URL строковый параметр 'ns'), название события (например, обозначенное в строке запроса URL как параметр 'ev'), и один или более параметров запроса. Параметры представлены или в XML для запросов POST или как пары имя-значение - для запросов GET.

Примерный запрос GET (например, запрос 103 данных) согласно изобретению является следующим:

URL: /mail/ev.owa?ns=CalendarView&ev=Refresh&d=l 1142004T00:00:00Z

В этом примере клиент (например, клиентский компонент 108) зарашивает сервер (например, серверный компонент 102), чтобы выполнить обработчик "Refresh" в пространстве имен "CalendarView". Клиентский компонент 108 передает параметр даты типа, названной "d" с значением 11/14/2004 в 12 часов. Серверный компонент 102 возвращает полезные данные разметки или JavaScript для этого представления, в зависимости от реализации.

Примерный запрос POST (например, запрос 103 данных) согласно изобретению является следующим:

URL: /mailserver/ev.owa?ns=Messaging&ev=SaveMessage

BODY:

<params>

<subject>Testemail</subject><to><item>userA@pageA.net</item><item>userB@pageA.net</item><to>

<body>Test something < /body > < /params >

В этом примере клиентский компонент 108 просит серверный компонент 102 выполнить обработчик 'SaveMessage' событий в пространстве имен 'Messaging'. Параметрами события являются subject (строка), к (массив строк) и body (строка). Ответом для этого события является результат HTTP, указывающий успех или ошибку. В этом случае никакая возвращенная разметка не является необходимой. Параметры могут быть в форме XML или формате любого другого языка, понятного серверу.

Обращаясь к фиг. 2, примерная последовательность операций иллюстрирует работу клиента и процессы сервера для передачи запрошенных данных. Последовательность операций согласно фиг. 2 отражает реализуемый компьютером способ создания и доставки данных от одного процесса к другому процессу. Способ включает в себя прием первым процессом, таким как клиентский компонент 108 на фиг. 1, запроса данных от пользователя на этапе 202 и идентификацию пространства имен, ассоциированного с принятым запросом, на этапе 204. Способ дополнительно включает в себя определение обработчика событий, ассоциированного с идентифицированным пространством имен, как функцию (в ответ на) принятого запроса на этапе 206 и заполнение параметра, ассоциированного с определенным обработчиком событий, как функцию принятого запроса на этапе 208. Способ также включает в себя создание форматированного запроса (например, запрос 103 данных на фиг. 1) с идентифицированным пространством имен, определенным обработчиком событий и заполненным параметром на этапе 210. Согласно способу передают от первого процесса ко второму процессу (например, серверному компоненту 102) созданный отформатированный запрос на этапе 212.

Способ согласно изобретению включает в себя прием вторым процессом отформатированного запроса от первого процесса на этапе 214. Согласно способу выбирают пространство имен на этапе 215 на основании принятого запроса. Способ также включает в себя выбор вторым процессом, как функции принятого отформатированного запроса, обработчика событий из множества обработчиков событий (например, множества обработчиков 104 событий на фиг. 1), сохраненных на одном или более считываемых компьютером носителях (например, области 106 памяти на фиг. 1) на этапе 216. Согласно способу синтаксически анализируют и проверяют правильность параметров в принятом запросе на этапе 217. Способ дополнительно включает в себя выполнение выбранного обработчика событий, чтобы сформировать данные результата на этапе 218 и передачу от второго процесса к первому процессу сформированных данных результата к первому процессу на этапе 220. Первый процесс принимает данные результата и, в одном примере, отображает данные пользователю.

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

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

Обращаясь к фиг. 3, примерная блок-схема иллюстрирует модули в серверном компоненте. Модули вызываются в пределах потока 302 запросов, порожденного серверным компонентом. В одном варианте осуществления обработчиками событий являются обработчики HTTP, осуществляющие интерфейс IHttpHandler. Изобретение вызывает метод ProcessRequest в этом интерфейсе, который позволяет классу обработчиков выполнять код, чтобы обработать запрос. Фабрика обработчиков HTTP является классом, который осуществляет интерфейс IHttpHandlerFactory. Такие объекты используются, чтобы создать экземпляры объектов обработчика HTTP, используемого для обработки запросов. В примере на фиг. 3 показывается класс фабрики обработчика HTTP по имени EventHandlerFactory 304. Изобретение (например, HTTP приложение 306) инициализирует объект (например, экземпляр 308 EventHandlerBase) этого класса и вызывает метод "GetHandler" интерфейса IHttpHandlerFactory, который создает экземпляр подходящего класса обработчика HTTP (например, подклассы EventHandlerBase) на основании пространства имен запроса. HTTP приложение 306 и HTTP приложение 306 EventHandlerBase обращаются к HTTP-контексту 314.

Объект EventContext 312 является структурой данных, которая содержит информацию о запросе (например, пространстве имен, имени события и параметрах запроса). EventHandlerRegistry 310 является классом, который служит в качестве архива информации о пространствах имен и их обработчиков событий, реализованных приложением, а также сделанных на заказ поддерживаемых структурах данных и перечислениях. Приложение регистрирует класс EventHandlerBase, используя этот архив 310 при запуске приложения. Изобретение сканирует класс (например, используя отражение), чтобы определить пространство имен, события в пространстве имен и параметры событий. Эта информация сохраняется и используется позже в течение обработки запроса и синтаксического анализа параметров.

Примерная последовательность операций выполнения запроса согласно изобретению проиллюстрирована на фиг. 3. Согласно изобретению принимают запрос данных в соответствии с изобретением, создают экземпляр класса EventHandlerFactory и вызывают (метод) GetHandler в отношении созданного экземпляра. Реализация GetHandler для EventHandlerFactory просматривает строку запроса, чтобы вычислить названия пространства имен и события, и исследует EventHandlerRegistry 310 на класс обработчика, соответствующего названиям пространства имен и события в строке запроса. Если согласно изобретению находят запрошенный обработчик событий, изобретение создает экземпляр этого обработчика событий. EventContext 312 также создается. Изобретение вызывает ProcessRequest в отношении обработчика событий. ProcessRequest проводит синтаксический анализ параметров запроса, используя класс синтаксического анализатора, специфический для самого запроса (например, является ли запрос глаголом GET или глаголом POST). Класс синтаксических анализов анализирует параметры в запросе и использует EventHandlerRegistry 310, чтобы сделать любые преобразования типов и гарантировать, что схема является корректной (например, гарантировать, что все параметры, требуемые этим обработчиком, установлены). Параметры могут быть сохранены в коллекции в контексте в этот момент. Согласно изобретению выполняют код обработчика событий, ассоциированного с обработчиком событий (например, выполняют метод в классе обработчика). Этот код обращается к параметрам в контексте, выполняет обработку и записывает ответ на запрашивающий объект в любом формате, указанном запрашивающим объектом.

Со ссылками на фиг. 4 примерная блок-схема иллюстрирует типовой набор классов обработчика событий, наследуемых от EventHandlerBase 402. EventHandlerBase 402 реализует интерфейс 404 IHttpHandler. CalendarEventHandler 406, MessagingEventHandler 408 и MessageViewEventHandler 410 наследуются из EventHandlerBase 402. Разработчики или другие пользователи могут создавать созданный на заказ обработчик событий, такой как показан на фиг. 4, посредством создания пространства имен, идентифицируя событие в пространстве имен и определяя параметры для события. Определяемое пользователем пространство имен, обработчик событий и/или параметр могут быть выбранными пользователем (например, новый обработчик событий в пределах существующего пространства имен) или разработаны пользователем (например, новое пространство имен). В одном варианте осуществления определяемый пользователем обработчик событий реализован как динамически загружаемая библиотека.

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

[EventNamespace ("Namespase1")]

internal classс TestEventHandler: EventHandlerBase

{

[Event("Event1")]

[EventParameter ("Param1", typeof (string))]

[EventParameter ("Param2", typeof (int))]

public void Event1 ()

{

string param1=

(string)Context.GetParamValue("Param1");

int param2=(int)Context.GetParamValue ("Param2");

Writer.Write("{0}+{1}={2}", param1, param2, param1 +param2).

}

}

В этом примере атрибут EventNamespace определяет название (имя) пространства имен на соединении, атрибут Event определяет название события на соединении, и атрибут EventParameter определяет имя параметра, тип и является ли параметр необязательным или нет. Чтобы использовать этот обработчик, разработчик обработчика записывает класс, который наследуется от EventHandlerBase 402, записывает события как методы, которые не имеют каких-либо параметров и возвращают результат void (пусто), определяет схему, используя соответствующие атрибуты, описанные выше, и регистрирует класс в серверном компоненте.

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

[EventStruct ("r")]

internal classс RecipientWellltem

{

[EventField ("dn")]

public string DisplayName;

[EventField ("em", true, "oof@pageA.net")]//true= необязательное поле

public string Email;

[EventField ("t")]

public int Type;

internal RecipientWelirtem ()

{

DisplayName=" ";

Email=" ";

Type = 0;

}

}

Примерная структура данных, указанная выше, закодирована так, как показано ниже.

< r dn = "display name " em = "email address" t = "1" / >

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

Примерная рабочая среда

Фиг. 5 иллюстрирует один пример вычислительного устройства общего назначения в форме компьютера 130. В одном варианте осуществления изобретения компьютер, такой как компьютер 130, подходит для использования в других чертежах, проиллюстрированных и описанных в настоящем описании. Компьютер 130 имеет один или более процессоров или устройств 132 обработки и системную память 134. В иллюстрированном варианте осуществления системная шина 136 подсоединяет различные элементы системы, включая системную память 134, к процессорам 132. Шина 136 представляет одну или более из любого из нескольких типов шинных структур, включающих в себя шину памяти или контроллер памяти, шину периферийных устройств, ускоренный графический порт и процессорную или локальную шину, используя любую из разнообразия шинных архитектур. В качестве примера и не ограничения, такая архитектура включает в себя шину архитектуры, соответствующей промышленному стандарту (ISA), шину микроканальной архитектуры (MCA), расширенную шину ISA (EISA), локальную шину Ассоциации по стандартам в области видеоэлектроники (VESA) и шину соединения периферийных компонентов (PCI), также известную как шина Mezzanine.

Компьютер 130 в обычном варианте имеет по меньшей мере некоторую форму считываемых компьютером носителей. Считываемые компьютерные носители, которые включают в себя и энергозависимые и энергонезависимые носители, сменные и несменные носители, могут быть любой доступной средой, к которой можно обращаться компьютером 130. В качестве примера и не ограничения, считываемые компьютерные носители содержат компьютерные запоминающие устройства и коммуникационные носители. Компьютерные запоминающие устройства включают в себя энергозависимые и энергонезависимые, сменные и несменные носители, осуществленные любым способом или технологией для хранения информации, такой как считываемых компьютером команд, структур данных, программных модулей или других данных. Например, компьютерные запоминающие устройства включают в себя ОЗУ, ПЗУ, СППЗУ, флэш-память или память по другой технологии, CD-ROM, цифровые универсальные диски (DVD) или другую оптическую память на дисках, магнитных кассетах, магнитной ленте, память на магнитном диске или другие магнитные запоминающие устройства, или любую другую среду, которая может использоваться, чтобы хранить желательную информацию, и к которой можно обращаться компьютером 130. Коммуникационные носители обычно воплощают считываемые компьютером команды, структуры данных, программные модули, или другие данные в модулируемом сигнале данных, таком как несущая, или другом транспортном механизме, и включают в себя любые носители доставки информации. Специалисты знакомы с модулируемым сигналом данных, который имеет одну или более из его набора характеристик, установленную или измененную таким образом, чтобы кодировать информацию в сигнале. Проводные носители, такие как проводные сети или непосредственное проводное соединение, и беспроводные носители, такие как акустический, РЧ, инфракрасное излучение, и другие беспроводные носители, являются примерами коммуникационных носителей. Комбинации любого из вышеупомянутых также включено в объем понятия считываемых компьютером носителей.

Системная память 134 включает в себя компьютерные запоминающие устройства в форме сменной и/или несменной, энергозависимой и/или энергонезависимой памяти. В иллюстрированном варианте осуществления системная память 134 включает в себя постоянное запоминающее устройство (ПЗУ) 138 и оперативное запоминающее устройство (ОЗУ) 140. Базовая система ввода/вывода 142 (BIOS), содержащая основные подпрограммы, которые помогают передавать информацию между элементами в компьютере 130, например, во время запуска, обычно сохраняется в ПЗУ 138. ОЗУ 140 обычно содержит данные и/или программные модули, которые являются немедленно доступными для и/или над которыми в настоящее время работают посредством процессора 132. В качестве примера и не ограничения фиг. 5 иллюстрирует оп