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

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

Иллюстрации

Показать все

Реферат

ПРЕДПОСЫЛКИ СОЗДАНИЯ ИЗОБРЕТЕНИЯ И УРОВЕНЬ ТЕХНИКИ

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

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

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

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

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

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

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

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

Фиг. 1 демонстрирует график ценности данных в динамике по времени;

Фиг. 2 демонстрирует рабочую среду рынка данных о событиях;

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

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

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

Фиг. 6 демонстрирует систему сбора и распределения данных о событиях;

Фиг. 7 демонстрирует пример системы сбора данных о событиях;

Фиг. 8 демонстрирует пример системы распределения данных о событиях;

Фиг. 9 демонстрирует систему сбора и распределения данных о событиях;

Фиг. 10 демонстрирует способ доставки данных; и

Фиг. 11 демонстрирует другой способ доставки данных.

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

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

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

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

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

Фиг. 2 демонстрирует пример рынка 202 данных, который может использовать систему распределения событий для предоставления данных. Фиг. 2 демонстрирует поставщика 204 данных, который может предоставлять данные на рынок 202 данных о событиях. Поставщик 204 данных может быть любым из множества различных источников, таких, но не ограничиваясь этим, как поставщики финансовых данных, поставщики спортивных информационных данных, поставщики новостной информации и т.д. Рынок 202 данных о событиях может быть посредником в операциях с данными, который принимает данные из множества разных источников и распределяет данные конечным потребителям (показаны как получатели 206).

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

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

В первом примере, продемонстрированном на Фиг. 3, счет за доставку данных выставляется поставщику 204 данных. Рынок 202 данных о событиях может предоставлять поставщику 204 данных статистические данные 208 о доставке данных, и поставщик 204 данных может самостоятельно выставлять счет получателям 206 данных.

Во втором примере, продемонстрированном на Фиг. 4, рынок 202 данных может выставлять счет напрямую получателям 206. Рынок 202 данных может затем взять свою долю и передать любые добавочные финансовые средства поставщику данных.

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

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

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

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

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

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

Фиг. 6 демонстрирует, что событие 104-1 отправляется в раздел 144 распределения. Раздел 144 распределения рассредоточивает события по множеству сегментов распределения. Сегмент 120-1 распределения используется в качестве аналога для всех сегментов распределения. Каждый сегмент распределения обслуживает ряд конечных пользователей или устройств, представленных подписками. Число подписок, обслуживаемых сегментом распределения, может отличаться от других сегментов распределения. В некоторых вариантах осуществления, число подписок, обслуживаемых сегментом, может зависеть от емкости сегмента распределения. В качестве альтернативы или дополнительно, сегмент распределения может быть выбран для обслуживания пользователей, основываясь на логической или географической близости к конечным пользователям. Это может позволить доставлять предупреждения конечным пользователям более своевременно.

В продемонстрированном примере, сегмент 120-1 распределения включает в себя средство 122-1 распределения. Средство 122-1 распределения обращается за информацией к базе 124-1 данных. База 124-1 данных включает в себя информацию о подписках с подробностями о соотнесенных целевых объектах 102 доставки. В частности, база данных может включать в себя такую информацию, как информация, описывающая платформы для целевых объектов 102, приложения, используемые целевыми объектами 102, сетевые адреса для целевых объектов 102, пользовательские настройки конечных пользователей, использующих целевые объекты 102 и т.д. Используя информацию в базе 124-1 данных, средство 122-1 распределения формирует пакет 126-1, причем пакет 126-1 включает в себя событие 104 (или, по меньшей мере, информацию из события 104) и маршрутную карту 128-1, идентифицирующую множество целевых объектов 102 из числа целевых объектов 102, которым будет отправлена информация из события 104-1 в качестве уведомления. Затем пакет 126-1 помещается в очередь 130-1.

Сегмент 120-1 распределения может включать в себя ряд средств доставки. Средства доставки выводят пакеты из очереди 130-1 и доставляют уведомления на целевые объекты 102. Например, средство 108-1 доставки может взять пакет 126-1 из очереди 130-1 и отправить информацию о событии 104 на целевой объект 102, идентифицированный в маршрутной карте 128-1. Таким образом, уведомления 134, включающие в себя информацию о событии 104-1, могут быть отправлены от различных сегментов распределения на целевые объекты 102 во множестве разных форматов, подходящих для разных целевых объектов 102 и точно определенных для конкретных целевых объектов 102. Это дает возможность создавать персонализированные уведомления 134, индивидуализированные для каждого конкретного целевого объекта 102, исходя из общего события 104-1, на границе системы доставки, а не проводить большое число персонализированных уведомлений через систему доставки.

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

В качестве основы, система согласно одному варианту осуществления использует инфраструктуру публикации/подписки, которая предоставляется в Windows Azure Service Bus, поставляемой компанией Microsoft Corporation, Редмонд, Вашингтон, но которая также присутствует в подобной форме и в различных других системах обмена сообщениями. Эта инфраструктура обеспечивает две функциональные возможности, которые облегчают описанную реализацию предлагаемого способа: Разделы и Очереди.

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

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

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

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

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

В реальной реализации, сбор может поддерживать реальные устройства согласования сбора для исходных событий от широкого разнообразия публичных и частных сетевых служб, включающих в себя каналы RSS, Atom и OData, почтовые ящики электронной почты, в том числе, но не ограничиваясь такими, поддерживающие протоколы IMAP и POP3, информационные источники 116 социальных сетей, такие, как ленты сообщений Twitter или стены Facebook, и подписки на внешние инфраструктуры публикации/подписки, такие как Windows Azure Service Bus или Simple Queue Service от Amazon.

Нормализация события

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

Для демонстрации нормализации события, рассмотрим сопоставление канала RSS или Atom с событием 104 (см. Фиг. 1 и 2). RSS и Atom представляют собой два стандарта сети Интернет, которые очень широко используются для публикации новостей и другой актуальной информации, часто в хронологическом порядке, и это помогает сделать такую информацию доступной для обработки в компьютерных программах в структурированном виде. RSS и Atom имеют общую очень похожую структуру и набор по-разному именуемых, но семантически идентичных, элементов данных. Итак, первый этап нормализации должен определить общие имена в качестве ключей для таких семантически идентичных элементов, которые определены в обоих стандартах, например, заголовок или резюме. Во-вторых, данные, которые встречаются только в одном, но не в другом стандарте, обычно сопоставляются с соответственным 'родным' именем. Помимо этого, эти виды каналов часто несут 'расширения', являющиеся элементами данных, которые не определены в основном стандарте, но используют возможности расширяемости в соответственных стандартах для добавления дополнительных данных.

Некоторые из этих расширений, в том числе, но не ограничиваясь этим, GeoRSS для геопозиционирования или OData для внедрения структурированных данных в Atom-каналы, сопоставляются универсальным способом, который является общим для разных источников 116 событий, так что подписчик на инфраструктуру публикации/подписки, в которой порождаются события, может интерпретировать информацию геопозиционирования единообразно, независимо от того, были данные собраны из RSS или Atom или ленты сообщений Twitter. Продолжая рассматривать пример с GeoRSS, простое выражение GeoRSS, представляющее географическую 'точку', может, соответственно, сопоставляться с парой числовых параметров 'Широта'/'Долгота', представляющих координаты в международной системе координат WGS84.

Расширения, которые несут комплексные, структурированные данные, такие как OData, могут реализовывать модель сопоставления, которая сохраняет комплексный тип структуры и данных, без усложнения основополагающей модели событий. Некоторые варианты осуществления проводят нормализацию до канонического и компактного представления комплексных данных, как JSON, и сопоставляют параметр комплексных данных, например, параметр OData 'Арендатор' комплексных данных типа 'Человек', с парой ключ/значение, причем ключом является имя 'Арендатор' параметра, а значение выражается комплексными данными, описывающими человека с именем, биографической информацией, а также адресной информацией, представленными в упорядоченной форме JSON. Если источником данных является XML-документ, как в случае RSS или Atom, значение может создаваться путем преобразования XML-данных в JSON с сохранением структуры, обеспечиваемой XML, но выравнивая такие частности XML, как атрибуты и элемент, подразумевая, что и атрибуты и элементы XML, которые являются подчиненными одного и того же узла XML-элемента, сопоставляются с параметрами JSON как 'узлы-братья', без различения в дальнейшем.

Источники и сегментирование

Архитектура согласно одному варианту осуществления фиксирует метаданные об источниках 116 данных в записях 'описание источника', которые могут быть сохранены в базе 138 данных источников. 'Описание источника' может иметь набор общих элементов и набор элементов, специфичных для источника данных. Общие элементы могут включать в себя имя источника, продолжительность временного интервала, в течение которого источник 116 считается действительным, удобочитаемое для человека описание и тип источника 116 для установления различий. Специфичные для источника элементы зависят от типа источника 116 и могут включать в себя сетевой адрес, учетные данные или другие значимые данные ключа безопасности для получения доступа к ресурсу, представленному этим адресом, и метаданные, которые дают указания устройству согласования сбора источника либо выполнять сбор данных определенным образом, возможно, предоставляя временной интервал для проверки RSS-канала, либо выполнять пересылку событий определенным образом, например, отделять события, собранные из новостного канала текущих событий, промежутками, по меньшей мере, в 60 секунд, чтобы получатели уведомлений имели возможность увидеть каждый краткий новостной сюжет на ограниченной поверхности экрана, если нужно создать впечатление непрерывности.

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

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

Вторая ось может быть различением по числовому идентификатору сегмента, выбранному из предварительно заданного диапазона идентификаторов. Идентификатор сегмента может быть получен из инвариантов, содержащихся в описании источников, таких, например, как имя источника и идентификатор арендатора. Идентификатор сегмента может быть получен из этих инвариантов с использованием хэш-функции (одним из многих вариантов является хэш-функция Дженкинса, см. http://www.burtleburtle.net/bob/hash/doobs.html), и результирующее значение хеш-функции вычисляется по нисходящей в диапазоне идентификаторов сегмента, возможно, с использованием функции модуля на значении хеш-функции. Диапазон идентификаторов выбирается так, чтобы быть больше (и может быть существенно больше), чем наибольшее число сегментов хранения, которое, как ожидается, необходимо для хранения всех описаний источников, когда-либо размещавшихся в системе.

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

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

Принадлежность и сегменты сбора

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

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

Планирование

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

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