МЕХАНИЗМ ДИНАМИЧЕСКОГО СИНТАКСИЧЕСКОГО АНАЛИЗА/КОМПОНОВКИ НА ОСНОВЕ СХЕМ ДЛЯ СИНТАКСИЧЕСКОГО АНАЛИЗА МУЛЬТИФОРМАТНЫХ СООБЩЕНИЙ Российский патент 2011 года по МПК G06F17/27 G06F7/00 

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

Данная заявка связана с Заявкой (США) номер ________, озаглавленной "ADAPTIVE FRONT END GATEWAY FOR SWITCHING TRANSACTIONS AND DATA ON UNRELIABLE NETWORKS USING CONTEXT-BASED RULES" (номер 16222U-020200US дела поверенного), зарегистрированной параллельно с данной и тем самым образом полностью содержащейся в данном документе по ссылке для всех целей.

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

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

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

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

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

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

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

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

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

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

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

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

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

Фиг.1 иллюстрирует систему для обработки транзакций согласно одному варианту осуществления настоящего изобретения.

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

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

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

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

Фиг.6 иллюстрирует децентрализованную систему множества шлюзов согласно одному варианту осуществления настоящего изобретения.

Фиг.7 иллюстрирует систему, которая демонстрирует шлюз как шлюз внешнего интерфейса согласно одному варианту осуществления настоящего изобретения.

Фиг.8 иллюстрирует систему, в которой шлюз - это Интернет-шлюз согласно одному варианту осуществления настоящего изобретения.

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

Фиг.10 иллюстрирует систему для обработки транзакций ISO 8583 согласно одному варианту осуществления настоящего изобретения.

Фиг.11 иллюстрирует систему для синтаксического анализа сообщений согласно одному варианту осуществления настоящего изобретения.

Фиг.12 раскрывает вариант осуществления шлюза согласно вариантам осуществления настоящего изобретения.

Фиг.13A иллюстрирует структуру для IMF-объекта согласно одному варианту осуществления настоящего изобретения.

Фиг.13B иллюстрирует атрибуты в определении сообщения согласно одному варианту осуществления настоящего изобретения.

Фиг.14A, 14B и 14C иллюстрируют возможное сообщение, иерархический формат с кодами идентификаторов объектов и IMF-объект для сообщения согласно одному варианту осуществления настоящего изобретения.

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

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

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

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

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

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

Шлюз

Обзор обработки

В одном варианте осуществления предусмотрена интеллектуальная коммутация транзакций. Транзакцией может быть авторизация кредитной карты, авторизация дебетовой карты или транзакция электронной проверки. Другие примеры транзакций включают в себя присуждение баллов или других премий в программе вознаграждений, проверка пароля для аутентификации Verified by Visa, выполнение денежного перевода, вычет платежа с карты предварительной оплаты, например, карты Visa Buxx или зарплатной карты, обработку дистанционного платежа с сотового телефона, пейджера, PDA и т.д., определение покрытия по страхованию здоровья, автомобиля и т.д. Клиент отправляет транзакцию в шлюз, который затем конфигурируется так, чтобы интеллектуально коммутировать транзакцию на процессор транзакций поставщика услуг. Клиентом может быть POS, компьютер магазина, подключенный по сети к POS-устройствам или ECR (электронным кассовым аппаратам), киоск (например, для купонов или денежного перевода), Интернет-сервер веб-узла и т.д.

Шлюз выполнен с возможностью принимать решения о коммутации на уровне приложения на основе контента уровня приложения транзакции, текущего состояния транспортного окружения и/или динамических правил. Контентом уровня приложения может быть информация, которая обрабатывается или используется процессором транзакций при обработке транзакции. В одном варианте осуществления информацией может быть информация уровня OSI-7. Этот уровень непосредственно обслуживает процессор транзакций или конечного пользователя. Он включает в себя такие приложения, как приложения авторизации кредитных карт, авторизации дебетовых карт и т.д. Примерные протоколы уровня приложений - это FTP (протокол передачи файлов), NFS (сетевая файловая система), CIFS (общая межсетевая файловая система), HTTP (протокол передачи гипертекстовых файлов), запрос к базе данных, SQL (язык структурированных запросов) и XML (расширяемый язык разметки). Например, при авторизации кредитных карт контент уровня приложений может включать в себя номер кредитной карты, номер лицевого счета (PAN), номер клиентского счета, общая сумма по транзакции и т.д. Процессор транзакций может использовать эту информацию, чтобы обрабатывать транзакцию.

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

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

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

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

Обзор системы

Фиг.1 иллюстрирует систему 100 для обработки транзакций согласно одному варианту осуществления настоящего изобретения. Как показано, система 100 включает в себя одного или более клиентов 102, один или более шлюзов 104, одну или более сетей 106 и один или более процессоров 108 транзакций. Последующее описание приводится в отношении одного шлюза 104, но следует понимать, что несколько шлюзов 104 может быть предусмотрено для того, чтобы выполнять любые функции, описанные ниже. Помимо этого, хотя шлюзы показаны рядом с клиентами, шлюзы также могут быть развернуты рядом с процессорами транзакций, между процессорами транзакций и сетями 106.

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

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

Шлюз 104 включает в себя систему, выполненную с возможностью принимать транзакции от клиентов 102 и маршрутизировать транзакции на процессоры 108 транзакций через сети 106. В одном варианте осуществления шлюз 104 размещается на границе сети 106. Например, шлюз 104 может находиться в точке доступа для клиента 102 или в помещениях для клиента 102. Границей сети 106 может быть точка, в которой транзакции могут быть сконфигурированы для маршрутизации через сеть 106. Например, шлюз 104 может выбирать процессор 108 транзакций и отправлять запрос в маршрутизатор сети 106. Транзакция может быть разбита на ряд пакетов. Маршрутизатор затем может маршрутизировать пакеты для транзакции через сеть 106 в процессор 106 транзакций.

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

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

Кроме того, сети 106 могут быть различных типов. Например, сетью 106-1 может быть сеть с асинхронным режимом передачи (ATM), которая маршрутизирует пакеты данных. Другой сетью 106-2 может быть беспроводная сеть, которая передает данные беспроводным способом. Дополнительно, другой сетью 106 может быть частная сеть для объекта, например, сеть VisaNet. Хотя показаны только две сети 106, следует понимать, что может быть предоставлено гораздо большее число сетей 106. Кроме того, следует понимать, что транзакции могут маршрутизироваться через несколько сетей 106. Например, транзакции могут маршрутизироваться через сеть 106-1, затем сеть 106-2, а затем в процессор 108 транзакций.

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

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

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

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

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

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

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

Соответственно, шлюз 104 может динамически выбирать процессор 108 транзакций для услуги, который может обработать транзакцию. Бизнес-логика, конкретная для выбранного процессора транзакций, также может выполняться в транзакции, например, транзакция может быть отформатирована так, чтобы выбранный процессор 108 услуг мог обработать ее. Транзакция после этого может быть отправлена через выбранную сеть 106 в выбранный процессор 108 транзакций. Посредством динамического выбора процессоров 108 транзакций и/или сетей 106 шлюз 104 изолирует клиентов 102 от любых отказов процессоров 108 транзакций и/или сетей 106. Соответственно, это предоставляет чрезвычайно высокую готовность услуги. Шлюз 104 изолирует клиента 102 от всех изменений, которые может потребоваться выполнить, что может вызывать простои процессора 108 транзакций.

Обзор шлюза 104

Фиг.2 иллюстрирует более подробное описание шлюза 104 согласно одному варианту осуществления настоящего изобретения. Как показано, шлюз 104 включает в себя один или более обработчиков 202 запросов, синтаксический анализатор 204 потока поступающих сообщений, менеджер 206 безопасности, адаптивный селектор 208 маршрута, обработчик 210 последовательности операций, компоновщик 212 потока исходящих сообщений, диспетчер 214 сообщений, координатор 216, модуль 218 администрирования, конфигурационный загрузчик 220, база 222 данных правил, база 224 данных контекстной информации и монитор 226 динамической информации.

Обработчики 202 запросов выполнены с возможностью принимать транзакции от клиентов 102. Клиенты 102 могут отправлять транзакции в различных протоколах и форматах, таких как протокол передачи гипертекстовых файлов (HTTP), протокол передачи файлов (FTP), расширяемый язык разметки (XML), стандарты ISO 8583 и т.д. Обработчики 202 запросов обеспечивают интерфейс для транзакций, отправляемых в различных протоколах и форматах, и предоставляют транзакции в синтаксический анализатор 204 потока входящих сообщений. Например, обработчик ISO-сообщений выполнен с возможностью принимать запросы ISO 8583 от клиентов 102 и передавать их в синтаксический анализатор 204 потока входящих сообщений. Кроме того, обработчик XML-сообщений, обработчик HTTP-запросов и обработчик FTP-запросов могут обрабатывать XML-, HTTP- и FTP-сообщения и/или запросы. Соответственно, обработчики 202 запросов позволяют шлюзу 104 принимать сообщения в различных протоколах и форматах. Хотя описаны вышеуказанные протоколы и форматы, следует понимать, что специалисты в данной области техники должны принимать во внимание другие форматы и протоколы, которые обработчики 202 запросов могут обрабатывать.

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

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

Адаптивный селектор 208 маршрута выполнен с возможностью коммутировать транзакцию на процессор 108 транзакций через сеть 106. Адаптивный селектор 208 маршрута коммутирует транзакцию на основе контента уровня приложений, текущего состояния транспортного окружения и/или динамических правил.

Адаптивный селектор 208 маршрута использует правила, находящиеся в базе 222 данных правил, и динамическую контекстную информацию, находящуюся в базе 224 данных контекстной информации, чтобы маршрутизировать транзакцию. Как упоминалось выше, контекстная информация может быть сохранена в базе 224 данных контекстной информации. В одном варианте осуществления контекстная информация может быть динамической. Монитор 226 динамической информации может отслеживать и определять контекстную информацию. Затем динамическая информация сохраняется в базе 224 данных контекстной информации. Примеры контекстной информации включают в себя готовность сетей 106, состояние исправности процессоров 108 транзакций, стоимость на транзакцию, время, требуемое для приложения, чтобы обработать предыдущую транзакцию на уровне приложений, и т.д. В одном варианте осуществления монитор 226 динамической информации может определять динамическую контекстную информацию во время исполнения, когда транзакция принимается. В другом варианте осуществления монитор 226 динамической информации может определять динамическую контекстную информацию через определенные интервалы.

Каждая различная услуга, осуществляемая посредством процессоров 108 транзакций, может указывать тестовые сообщения, которые могут быть выполнены монитором 226 динамической информации. Тестовые сообщения отправляются и дают возможность информации быть собираемой на основе состояния процессора 108 транзакций и/или сети 106. Например, монитор 226 динамической информации может проверять сеть командой PING, чтобы определять то, доступна ли сеть. Если с процессором 108 транзакций или сетью 106 не может быть установлено соединение, они могут рассматриваться как недоступные, и информация состояния отражается в базе 224 данных контекстной информации. Если со всеми процессорами 108 транзакций для услуги не могут быть установлены соединения, то услуга может рассматриваться как недоступная. Шлюз 104 может определять другого поставщика услуг, который в этом случае предоставляет услугу. Кроме того, время, которое требуется приложению в процессоре 108 транзакций для того, чтобы обработать транзакцию, может быть измерено. Например, измеряется то, сколько требуется приложению для того, чтобы авторизовать авторизацию кредитной карты. Данное измерение предоставляет контекст уровня приложений, который может быть использован для того, чтобы коммутировать транзакцию.

База 222 данных правил включает в себя правила для определения услуги для транзакции помимо сети 106 и процессора 108, чтобы обработать транзакцию. Правила также могут выражать критерии для клиента. Например, чтобы услуга была выбрана, определенная контекстная информация и контент уровня приложений должно удовлетворять правилам. Клиенты могут предоставлять конкретные для клиентов правила, которые могут быть использованы для того, чтобы выбирать услугу для транзакции. В одном примере, когда транзакция принимается для клиента 102, адаптивный селектор 208 маршрута может определять заданные клиентом правила выбора и определять услугу, которая может обрабатывать транзакцию. Чтобы скоммутировать транзакцию на поставщика услуг, который предоставляет услугу, контент уровня приложений определяется из транзакции, и/или динамическая контекстная информация определяется из базы 224 данных контекстной информации. Контент уровня приложений и/или контекстная информация применяется к правилам, чтобы определить поставщика услуг, который может обработать транзакцию согласно правилам. Например, на основе конкретных факторов, таких как затраты, клиенты 102 могут указывать, что самая дешевая услуга должна быть выбрана первой, но если недоступна, должна быть выбрана вторая более дорогая услуга. Кроме того, на основе контента уровня приложений, такого как номера счетов, транзакции могут быть коммутированы на конкретную услугу кредитной карты. Например, определенные номера счетов могут указывать кредитную карту относительно дебетовой карты либо то, что конкретная система баллов или вознаграждений применяется. Другие номера счетов или поля могут указывать необходимость в других услугах, таких как денежный перевод или проверка пароля (к примеру, Verified by Visa). Помимо этого, контент уровня приложений может включать в себя местоположение клиента и любые региональные либо конкретные для страны нормы, которые диктуют то, должна ли транзакция быть обработана локально или отправлена процессору 108 в другой стране.

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

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

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

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

Диспетчер 212 сообщений выполнен с возможностью отправлять транзакцию в процессор 108 транзакций. Диспетчер 214 может обеспечивать то, что транзакция достигает выбранного процессора 108 транзакций. Он может управлять подключениями к различным процессорам 108 транзакций, пытаться переподключиться к отказавшим процессорам 108 транзакций, а также предоставлять состояние процессоров 108 транзакций и сетей 106 в монитор 226 динамической информации. В одном варианте осуществления транзакция может быть пакетирована, т.е. разбита на последовательность пакетов и отправлена в маршрутизатор. Маршрутизатор может маршрутизировать пакеты через сеть 106 в процессор 108 транзакций.

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

Динамическая загрузка правил

После первоначальной регистрации услуги (описана ниже) правила и бизнес-логика, реализуемые шлюзом 104, могут быть динамически изменены. Модуль 218 администрирования и конфигурационный загрузчик 220 выполнены с возможностью динамически загружать изменения в базу 222 данных правил и обработчик 210 последовательности операций.

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

Модуль 218 администрирования выполнен с возможностью предоставлять возможность выполнения административных действий. Модуль 218 администрирования может быть использован пользовательским агентом для того, чтобы администрировать один или более шлюзов 104. Например, модуль 218 администрирования может быть использован для того, чтобы задавать новые правила в базе 222 данных правил или динамически изменять правила маршрутизации. Кроме того, модуль 218 администрирования также может быть использован для того, чтобы загружать и выгружать новые спецификации последовательностей операций для обработчика 210 последовательности операций, запускать и останавливать бизнес-логику и загружать и выгружать конфигурации. Конфигурационный загрузчик 220 далее конфигурируется так, чтобы выполнять изменения.

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

Обработка транзакции

Фиг.3 иллюстрирует упрощенную блок-схему 300 последовательности операций способа для обработки транзакций согласно одному варианту осуществления настоящего изобретения. На этапе 302 транзакция принимается от клиента 102. Транзакцией может быть любой тип транзакции, например, авторизация кредитной карты, транзакция с чеком и т.д.

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

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

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

На этапе 310 применяются правила, чтобы определить процессор транзакций и/или сеть 106, на которую коммутировать транзакцию для услуги. Это решение может быть определено на основе контента уровня приложений и/или текущего состояния транспортного окружения, как применяемого к правилам. Например, определяется услуга для того, чтобы обработать транзакцию. После этого определяется применимый процессор 108 транзакций на основе готовности сети.

Кроме того, услуга может быть ассоциативно связана с различными процессорами 108 транзакций и сетями 106. Например, авторизации кредитных карт могут быть выполнены с возможностью отправляться в определенные процессоры 108 транзакций. Дополнительно, транзакции с чеками могут быть выполнены с возможностью отправляться во второй набор процессоров 108 транзакций. Эти правила определяются для клиента и/или услуги транзакции.

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

На этапе 314 транзакция может быть скоммутирована на выбранный процессор 108 транзакций через сеть 106.

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

Создание и подписка на услуги

Как упоминалось выше, правила могут быть динамически загружены в базу 222 данных правил. Фиг.4 иллюстрирует упрощенную блок-схему 400 последовательности операций способа загрузки правил в шлюз 104 для услуги, предоставляемой процессором 108 транзакций, согласно одному варианту осуществления настоящего изобретения. На этапе 402 принимается запрос на создание услуги. Например, поставщик услуг может попытаться зарегистрировать услугу посредством отправки запроса на создание услуги, который задает услугу, которая предлагается поставщиком услуг. Альтернативно, шлюз 104, ассоциативно связанный с процессором транзакций или другим поставщиком услуг, может динамически оповещать о новых услугах, и шлюз, ассоциативно связанный с клиентом, может определять то, следует ли инициировать регистрацию на эти новые услуги. Новой услугой может быть услуга денежного перевода, новая балльная программа и т.д.

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

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

Следовательно, когда услуга создана и опубликована, клиенты 108 могут подписываться на услугу. Фиг.5 иллюстрирует упрощенную блок-схему 500 способа подписки на услугу согласно одному варианту осуществления настоящего изобретения. На этапе 502 от клиента 108 принимается запрос, чтобы подписаться на созданную услугу. Запрос может принят посредством веб-портала или посредством других способов. Клиенты 102 могут обращаться и осуществлять доступ к узлу 104 непосредственно.

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

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

На этапе 508 эти правила могут быть динамически загружены в базу 222 данных правил. Следовательно, услуга может быть сразу доступна клиенту 108, который подписывается на услугу.

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

На этапе 512 определения последовательности операций, сформированные на этапе 510, могут быть динамически загружены конфигурационным загрузчиком 220.

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

Децентрализация правил для услуг

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

Фиг.6 иллюстрирует систему 550, показывая децентрализованную систему шлюзов 104 согласно одному варианту осуществления настоящего изобретения. Как показано, проиллюстрировано множество клиентов 102 и шлюзов 104. Шлюзы 104 размещаются на границе одной или более сетей 106.

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

Шлюз 104 выполнен с возможностью обрабатывать транзакции для клиентов 102, с которыми он соединен на границе сети 106. Например, шлюз 104-1 выполнен с возможностью обрабатывать транзакции для клиента 102-1, а шлюз 104-2 выполнен с возможностью обрабатывать транзакции для клиента 104-2. Шлюз 104-1 сохраняет информацию по услугам, предоставляемым клиенту 102-1, а также информацию, касающуюся предпочтений клиента 102-1. То же применимо и к другим шлюзам 104 и клиентам 102.

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

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

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

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

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

Сценарии развертывания

Шлюзы 104 могут развертываться во множестве различных сценариев. Например, шлюз 104 может быть развернут как внешний шлюз в частной сети, как Интернет-шлюз и/или как беспроводной шлюз. Фиг.7 иллюстрирует систему 600, которая показывает шлюз 104 как внешний шлюз согласно одному варианту осуществления настоящего изобретения. Система 600 подключает одного или более клиентов 102 к одному или более процессоров 108 транзакций по неравноправным сетям 106. Процессорами 108 транзакций может быть любая система, которая может обрабатывать транзакцию от клиента 102. Например, Visa, MasterCard и т.д. могут владеть процессорами транзакций по кредитным и дебетовым картам, а банк-член Федеральной резервной системы (запрашивающая/выдающая сторона) может быть клиентом 102.

Центр 602 клиентских данных может принимать транзакции от клиента 102. Транзакциями могут быть авторизации кредитных карт или транзакции с дебетовыми картами. Центром данных может быть, например, центральный компьютер, подключенный посредством частной сети клиента к нескольким POS-устройствам. Шлюз 104 обрабатывает транзакции и интеллектуально коммутирует транзакции на центр 108 данных процессора транзакций. Например, если транзакцией является транзакция Visa, центры A и B данных процессора транзакций могут быть ассоциативно связаны с Visa. Если транзакцией является транзакция MasterCard, могут быть выбраны центры C данных процессора, поскольку они ассоциативно связаны с MasterCard.

Шлюз 104 определяет надлежащий процессор 108 транзакций и сеть 106, по которой маршрутизировать транзакцию. Далее транзакция отправляется в маршрутизатор 604, который после этого может маршрутизировать транзакцию. В одном варианте осуществления маршрутизатор 604 может маршрутизировать пакеты на выбранный процессор 108 транзакций через сеть 106.

Фиг.8 иллюстрирует систему 700, в которой шлюз 204 - это Интернет-шлюз согласно одному варианту осуществления настоящего изобретения. Интернет-клиент 702 включает в себя клиента 102. Клиент 102 может отправлять транзакции в шлюз 104 через Интернет 704. Шлюз 104 может быть сконфигурирован под конкретные услуги, требуемые для интерактивных покупок, такие как обычная авторизация кредитной карты, аутентификация пароля (Verified by Visa), обработка вознаграждений или баллов и т.д.

Шлюз 104 предоставляет возможности подключения к различным процессорам 108 транзакций клиента 102. Шлюз 104 может принимать HTTP(s)- и другие XML-запросы. На основе контента уровня приложений и текущего состояния транспортного окружения могут быть выбраны услуга и процессор 108 транзакций. Поскольку транзакция, возможно, отправлена в HTTP- или любом другом XML-запросе, шлюз 104 может преобразовать сообщение в формат, ожидаемый процессором 108 транзакций, до коммутации транзакции. Например, процессор 108 транзакций может потребовать, чтобы сообщение было обработано в формате ISO 8583. В типичном варианте, когда POS-устройство обрабатывает транзакцию, транзакция может быть отправлена в формате ISO 8583. Тем не менее, когда транзакция обрабатывается посредством Интернет-шлюза, Интернет-клиент 702 может не быть сконфигурирован на то, чтобы отправлять сообщение ISO 8583. Таким образом, шлюз 104 выполнен с возможностью форматировать сообщение в формат ISO 8583, требуемый процессором 108 транзакций.

В одном примере шлюз 104 может обрабатывать Интернет-транзакции от Интернет-клиента 702. Интернет-клиент 702 отправляет HTTP(s)-запрос в шлюз 104. Шлюз 104 преобразует HTTP(s)-запрос в канонический внутренний формат сообщения. После этого для транзакции может выполняться любая бизнес-логика. В одном примере данные уровня приложения могут быть изменены, чтобы соответствовать формату, требуемому процессором 108 транзакций. Например, XML-транзакция может быть преобразована в формат ISO 8583. Далее шлюз 104 интеллектуально коммутирует транзакцию на процессор 108 транзакций.

Процессор 108 транзакций обрабатывает транзакцию и отправляет ответ обратно в шлюз 104. Этот ответ может быть в специфичном для процессора транзакций формате. Затем шлюз 104 компонует HTTP(s)-ответ и отправляет его Интернет-клиенту 702. Соответственно, транзакция через Интернет может быть обработана с помощью шлюза 104.

Фиг.9 иллюстрирует систему 800, в которой 104 шлюз используется в качестве беспроводного шлюза согласно одному варианту осуществления настоящего изобретения. Шлюз может принимать беспроводные сообщения от пользовательского мобильного телефона, PDA, пейджера и т.д. Шлюз 104 может быть выполнен с возможностью поддерживать различные беспроводные форматы, например, протокол приложений для беспроводной связи (WAP), протокол мобильных информационных устройств (MIDP), JQME и т.д. MIDlet отправляет запросы в XML-формате по таким сетям, как глобальная система мобильной связи (GSM) или общая служба пакетной радиопередачи (GPRS). Шлюз 104 может преобразовывать рабочие данные входящих запросов в канонический внутренний формат сообщений. Внутренний формат сообщений (IMF) затем может быть обработан посредством бизнес-логики. Компоновщик 212 потока исходящих сообщений преобразует IMF в рабочие данные ответа для отправки в процессор 108 транзакций. Следовательно, беспроводные транзакции могут быть обработаны шлюзом 104.

Далее будет описана беспроводная транзакция. В одном варианте осуществления беспроводной клиент 808 инициирует беспроводную транзакцию оплаты посредством отправки XML-запроса по HTTP(s)/GSM/GPRS. Шлюз 104 принимает XML-запрос и преобразует его в канонический внутренний формат сообщений до обработки запроса. Контент уровня приложений в транзакции используется помимо текущего состояния транспортного окружения, чтобы коммутировать транзакцию на процессор 108 транзакций. В зависимости от выбранного процессора 108 транзакций обработчик 210 последовательности операций может осуществлять бизнес-логику для транзакции. Затем транзакция отправляется в процессор 108 транзакций.

Процессор 108 транзакций определяет клиентский банк (или выдающую сторону) 802 и маршрутизирует сообщение в выдающую сторону 802. Выдающая сторона 802 обрабатывает запрос и отправляет ответ обратно в процессор 108 транзакций. Затем процессор 108 транзакций отправляет ответ (в формате процессора транзакций) обратно затребовавшей стороне 104. Шлюз 104 принимает ответ, преобразует его в XML-формат и отправляет его беспроводному клиенту 808. Соответственно, шлюз 104 выполнен с возможностью маршрутизировать беспроводные транзакционные платежи.

Фиг.10 иллюстрирует систему 900 для обработки транзакций ISO 8583 согласно одному варианту осуществления настоящего изобретения. Как показано, банк 902 выдающей стороны и банк 904 запрашивающей стороны принимают участие в транзакции. Клиентский компьютер 102 в банке 904 выдающей стороны отправляет запрос ISO 8583 в шлюз 104. Шлюз 104 использует контент уровня приложения и текущее состояние транспортного окружения, чтобы выбрать процессор 108 транзакций, чтобы обработать запрос. Сообщение далее отправляется в выбранный процессор 108 транзакций после того, как вся бизнес-логика выполнена по запросу.

Процессор 108 транзакций обрабатывает транзакцию и коммутирует ее к соответствующей выдающей стороне 902 для авторизации. Выдающая сторона отправляет ISO 8583 обратно в процессор 108 транзакций. После этого процессор 108 транзакций отправляет ответ в шлюз 104, который далее отправляется клиенту 102 банка 904 запрашивающей стороны.

В одном примере процессор 108 транзакций может быть недоступен. В этом случае, например, процессор A, центр 01 данных может быть недоступен. Это может быть предпочтительный процессор для клиента 102 по услуге. В таком случае шлюз 104 отправляет транзакцию на второй процессор, процессор A, центр 02 данных. Шлюз 104 может продолжать проверку готовности основного центра данных и, после того как он становится доступным, может начать маршрутизацию сообщений на основной центр данных. Перенаправление транзакций выполняется способом, который прозрачен клиенту 102. Следовательно, простой ни одного процессора 108 транзакций не допускается с помощью интеллектуальной коммутации шлюза 104.

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

Синтаксический анализ/компоновка сообщений

Обзор механизма синтаксического анализа и компоновки

Фиг.11 иллюстрирует систему 1000 для синтаксического анализа сообщений согласно одному варианту осуществления настоящего изобретения. Система 1000 выполнена с возможностью синтаксически анализировать потоки мультиформатных сообщений, такие как сообщения ISO 8583, в канонический формат сообщений, упоминаемый в данном документе как внутренний формат сообщений (IMF), и компоновать потоки мультиформатных сообщений, такие как сообщения ISO 8583, из IMF. Хотя описаны потоки финансовых сообщений, следует понимать, чтобы любые потоки мультиформатных сообщений могут синтаксически анализироваться и компоноваться системой 1000.

Механизм 1004 синтаксического анализа/компоновки соответствует синтаксическому анализатору 204 потока входящих сообщений и компоновщику 212 потока исходящих сообщений по фиг.2. Хотя не все компоненты, показанные на фиг.2, показаны на фиг.11, следует понимать, что эти компоненты могут быть включены в систему 1000. Дополнительно, механизм 1004 синтаксического анализа/компоновки может быть включен в шлюз 104, но также может быть включен в другие компоненты. Например, механизм 1004 синтаксического анализа/компоновки может быть совместим с любыми программными приложениями, которые обрабатывают данные в формате данных, отличном от других разнородных систем.

Механизм 1004 синтаксического анализа/компоновки выполнен с возможностью принимать поток 1010 входящих сообщений из системы 1006 и синтаксически анализировать сообщение во внутренний формат сообщений. Внутренний формат сообщений (IMF) после этого может быть обработан посредством других компонентов, таких как приложение бизнес-логики, показанное в шлюзе 104. После того как компоненты в шлюзе 104 обрабатывают сообщение в IMF, механизм 1004 синтаксического анализа/компоновки компонует поток 1012 исходящих сообщений из обработанного IMF. Поток 1012 исходящих сообщений далее может быть отправлен в систему 1008 или возвращен в исходящую систему 1006.

Системами 1006 и 1008 могут быть любые системы, которые выполнены с возможностью отправлять сообщения 1010 и/или принимать сообщения 1012 от механизма 1004 синтаксического анализа/компоновки (или шлюза 104). В одном варианте осуществления системами 1006 и 1008 могут быть устройства кассового терминала, устройство смарт-карт, процессоры 108 транзакций, любая система, выполненная с возможностью обрабатывать транзакции, например, запрашивающая сторона, выдающая сторона, поставщик услуг, аутентификатор транзакций и т.д. Системы 1006 и 1008 могут отправлять/принимать сообщения во многих различных форматах, например, сообщения ISO 8583, расширяемого языка разметки (XML), HTML и т.д. Поток входящих сообщений также может быть в любой из нескольких схем кодирования, например, ASCII, EBCDIC, BCD и т.д., и иметь различные типы данных, такие как числовой, строковый, байтовый массив и т.д.

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

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

Схемы и все ассоциативно связанные обработчики, еще не загруженные, могут быть загружены из файла 1026 определения схемы в таблицу 1028 схем и таблицу 1030 обработчиков с помощью загрузчика 1024 схем. Таблица 1026 схем включает в себя различные схемы, обозначенные как схема name 1, name 2,..., name N. Для каждого формата сообщений, который может синтаксически анализироваться и компоноваться механизмом 1004 синтаксического анализа/компоновки, может быть предусмотрена соответствующая схема. Каждое имя схемы ассоциативно связано с объектом схемы, который задает "грамматику", структуру потока сообщений во внешнем формате. Структура может включать в себя очередность полей, тип полей, длину, кодирование символов, а также другие поля, которые являются необязательными или обязательными. Новая схема и скомпилированные обработчики могут быть загружены и использованы механизмом 1004 синтаксического анализа/компоновки без перекомпиляции механизма 1004 синтаксического анализа/компоновки.

Последовательность операций синтаксического анализа/компоновки

Далее описывается примерная последовательность операций. Как показано на фиг.11, когда принимается сообщение, программа бизнес-логики вызывает механизм 1004 синтаксического анализа/компоновки. Сообщение 1010 (поток сообщений в проводном формате) отправляется в механизм синтаксического анализа/компоновки, где он сначала принимается компонентом 1016 синтаксического анализатора. Приложение бизнес-логики также предоставляет имя 1011 схемы в компонент 1016 синтаксического анализатора. Компонент синтаксического анализатора создает объект внутреннего формата сообщений (IMF), в котором следует хранить значения из полей сообщения после того, как они преобразованы в IMF. В одном варианте осуществления компонент 1016 синтаксического анализатора обнаруживает источник сообщения 1010 и определяет то, какая схема требуется для сообщений 1010, отправляемых из источника. В другом варианте осуществления информация в сообщении 1010 может быть синтаксически проанализирована так, чтобы определить формат данных и тем самым соответствующую схему, которая должна быть использована. Дополнительно, сообщение 1010 может указывать то, какая схема соответствует формату данных.

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

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

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

Фиг.12 иллюстрирует приложение 1102 бизнес-логики, которое использует IMF-объект 1018 для того, чтобы осуществлять все услуги, предоставляемые шлюзом 104. Приложение 1102 бизнес-логики оперирует с IMF-объектом 1018. Операции могут включать в себя маршрутизацию уровня приложений, например, определение банка или центра обработки выдающей стороны, чтобы отправить в него сообщение. Дополнительно, услуги могут выполняться для сообщения, такие как форматирование уровня приложений потока сообщений, ведение журнала, создание временных меток, создание новых полей, требуемых для ответа или дополнительной обработки и т.д. Приложение бизнес-логики может выполнять предварительную обработку для выдающей стороны или финансовой сети либо может выполнять локальную обработку, которая была загружена для работы в автономном режиме. Например, сообщения авторизации для покупок менее чем на 50 долларов могут быть разрешены, а сообщение ответа отправляется без необходимости перенаправлять сообщение в финансовое учреждение для утверждения. Приложение 1102 бизнес-логики выполнено с возможностью обрабатывать данные во внутреннем формате сообщений, а не внешних форматах. Следовательно, приложение 1102 бизнес-логики изолировано от всех внешних форматов, которые используются посредством других систем, за счет синтаксического анализа сообщения в IMF.

Структура IMF

Фиг.13A иллюстрирует структуру IMF 1018 согласно одному варианту осуществления настоящего изобретения. Как показано, в IMF 1018 предусмотрено N полей. Поля могут быть массивом полей, где каждое поле также может включать в себя любое число дочерних полей, которые, в свою очередь, могут включать в себя "внучатые" поля и т.д., в иерархической структуре. Например, поле 1 включает в себя дочерние поля 1.1, 1.2,..., 1.N. Поля 1.2,..., 1.N также могут включать в себя любое число дочерних полей (не показаны). Когда сообщение принимается, только фактически используемые поля заполняются данными.

Фиг.14B иллюстрирует иерархический формат с кодами идентификаторов объектов, индексами для определений полей, показанных на фиг.13A. OID предоставляет возможность индексирования различных полей в IMF-объекте 1018. Доступ к определению полей в IMF-объекте 1018 осуществляется с помощью OID. В одном варианте осуществления OID - это восьмибайтовое число, которое представляется посредством показанного точечного десятичного представления. OID для первого поля кодируется как 1.0.0. Все подполя кодируются как 1.1.0, 1.2.0 и т.д. Второе поле кодируется как 2.0.0, а все подполя кодируются как 2.1.0, 2.2.0 и т.д.

Структура схемы

Фиг.13B иллюстрирует примерную схему. Адрес схемы - это первая строка, определение сообщения (MessageDef). Схема включает в себя грамматику и указатели на обработчики для каждого поля в сообщении. В показанном примере первое поле сообщения идентифицируется посредством объекта определения поля (FieldDef) 1202 с индексом 1.0.0. Это также упоминается как OID-атрибут 1202. После индекса для этого поля идет идентификатор обработчика 1204, который должен быть выбран (HDR). Остальные элементы в этой строке являются определениями грамматики для данного конкретного поля. Эти определения полей описывают свойства поля, такие как очередность поля, тип поля, длина, кодирование символов, названия требуемых обработчиков и т.д. Определения полей могут быть использованы для того, чтобы синтаксически анализировать/компоновать поля, кодированные в различных кодировках, таких как ASCII, EBCDIC, BCD и т.д., и различных типах данных, таких как числовой, строковый, байтовый массив и т.д. Таким образом, потоки мультиформатных сообщений могут быть обработаны с помощью определения сообщений. В одном варианте осуществления схема - это метаданные в форме XML-схемы.

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

Атрибут 1204 обработчика - это название поля. Обязательный/необязательный атрибут 1206 указывает то, является поле обязательным или необязательным в сообщении. Атрибут 1208 первого формата данных - это формат данных для значения поля, обнаруженного во внешнем формате (также упоминаемого как проводной формат). Атрибут 1210 второго формата данных - это внутренний формат, в котором поле сохраняется в IMF и обрабатывается посредством бизнес-логики.

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

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

Восьмой атрибут 1216 указывает число подполей в поле.

Примерные поля сообщений, используемых в IMF (внутреннем формате сообщений)

Фиг.14A иллюстрирует пример полей, используемых для конкретного объекта 1010 сообщения, который включает в себя ряд идентификаторов объекта (OID) для различных полей, OID 1.0.0, 1.1.0, 1.1.1, 2.0.0, 2.2.0, 4.0.0 и 4.1.0. Это поля, на которые указывает схема по фиг. 13B. Таким образом, для этого примерного сообщения только поля, идентифицированные на фиг.14C, должны быть заполнены в объекте сообщений, который показан на фиг.13A. Фиг.14B иллюстрирует часть всех идентификаторов иерархических объектов для полного набора полей во внутреннем формате сообщений. Как можно видеть, сообщение 1010 включает в себя только часть этих полей, которая ему требуется. Например, идентификаторы объектов 1.2.0, 3.0.0 и 4.2.0 не используются. Отметим, что эти поля могут иметь любое число дочерних полей.

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

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

Обязательные поля также могут быть добавлены в IMF-объект 1018. Некоторые поля могут требоваться модулем 1102 бизнес-логики или процессоров 108 транзакций. Если определено, что поле, которое обязательно должно быть использовано, не включено в принимаемое сообщение 1010, поле может быть заполнено модулем бизнес-логики для включения в сообщение, которое должно быть скомпоновано для повторной передачи. Таким образом, "обязательные" поля в схеме по фиг.13B могут быть добавлены в IMF-объект 1018, если не включены в сообщение 1010.

Инициализация механизма синтаксического анализа/компоновки

Фиг.15 иллюстрирует упрощенную блок-схему 1400 последовательности операций способа инициализации механизма 1004 синтаксического анализа/компоновки при запуске приложения бизнес-логики. На этапе 1402 от приложения принимается запрос на инициализацию. Запрос включает в себя размещение одного или более файлов 1026 определения схемы.

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

На этапе 1406 схемы в файле 1026 определения схем загружаются в реестр 1022 с диска или другого носителя хранения в ДОЗУ с помощью загрузчика 1024 схем.

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

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

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

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

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

Добавление или обновление схемы

Фиг.16 иллюстрирует упрощенную блок-схему 1500 последовательности операций способа для динамического добавления или обновления схемы в механизме 1004 синтаксического анализа/компоновки согласно одному варианту осуществления настоящего изобретения. На этапе 1502 из приложения принимается запрос на то, чтобы динамически добавить или обновить схему. Запрос включает в себя размещение одного или более файлов 1026 определения схемы, которые включают в себя новую или обновленную схему.

На этапе 1504 проверяется достоверность схем, найденных в файлах 1026 определения схемы.

На этапе 1506 схемы в файлах 1026 определения схем загружаются в реестр 1022. Если обновленная схема содержит набор новых определений полей или обновленных определений полей, только новые или измененные определения полей могут быть загружены в реестр 1022. При добавлении или обновлении схемы соответствующие структуры данных блокируются от записи, чтобы обеспечить то, что текущие обрабатываемые сообщения не повреждены в результате изменения схемы. Текущие сообщения продолжают использовать предыдущую версию схемы, пока загрузчик 1024 схемы загружает обновленную версию схемы.

На этапе 1508 все обработчики, указанные в объекте определения сообщения, загружаются в реестр 1022. Механизм 1004 синтаксического анализа/компоновки может выполнить проверку, чтобы определить то, присутствуют ли уже какие-либо обработчики в реестре 1022, и можно ли не загружать повторно эти обработчики в реестр 1022. Тем не менее, если какие-либо обработчики изменены, измененные обработчики загружаются.

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

Блок-схема последовательности операций синтаксического анализа

Фиг.17 иллюстрирует упрощенную блок-схему 1600 последовательности операций способа для синтаксического анализа потока 1010 входных сообщений согласно одному варианту осуществления настоящего изобретения. На этапе 1602 схема сообщения определяется. Схема соответствует формату данных, в котором составлен поток 1010 входных сообщений.

На этапе 1604 все обработчики объекта определения сообщений определяются из указателей в схеме.

На этапе 1606 обработчики для каждого поля прикрепляются к полю.

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

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

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

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

Блок-схема последовательности операций процесса компоновки

Далее описывается процесс компоновки со ссылкой на фиг.18. Фиг.18 иллюстрирует упрощенную блок-схему 1700 последовательности операций компоновки потока 1012 выходных сообщений из IMF-объекта 1018 согласно одному варианту осуществления настоящего изобретения. На этапе 1702 определяется название схемы и IMF-объект 1018. В одном варианте осуществления сначала определяется IMF-объект 1018. Название схемы может быть определено на основе информации в IMF-объекте 1018. Например, название схемы может быть сохранено в информации IMF-объекта 1018. Кроме того, название схемы может быть определено посредством канала или системы назначения, в которую должна быть отправлена информация в IMF-объекте 1018.

На этапе 1704 объект определения сообщения используется для того, чтобы адресовать схему в реестре 1022. На этапе 1706 также определяются все обработчики, требуемые для схемы.

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

На этапе 1710 значение преобразуется из поля в IMF-объекте 1018 согласно атрибутам определения поля. Соответственно, значение, найденное в IMF-формате, преобразуется в формат, совместимый с другой системой.

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

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

Альтернативы

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

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

Изобретение относится к области обработки данных, а более конкретно к высокопроизводительному и при этом очень гибкому механизму синтаксического анализа/компоновки. Техническим результатом является расширение функциональных возможностей в части обеспечения возможности приема и обработки электронных сообщений в различных форматах, принимаемых с помощью приложения, изолированного от всех внешних форматов, которые используются посредством других внешних форматов. Механизм преобразует сообщения в различных форматах в общий формат, и сообщение общего формата затем обрабатывается посредством приложения бизнес-логики. Синтаксический анализатор исследует сообщение и определяет надлежащую схему для конкретного формата принятого сообщения. Схема - это структура данных в реестре схем, которая включает в себя грамматическую структуру для принимаемого формата, а также указатели на обработчики для преобразования разных полей сообщения во внутренний формат сообщений с помощью грамматической структуры ("грамматика" может включать в себя очередность поля, тип поля, длину, кодирование символов, необязательные и обязательные поля и т.д.). Обработчики компилируются по отдельности. По мере того как форматы изменяются, новые форматы или изменения в старые форматы могут динамически добавляться в механизм синтаксического анализа/компоновки посредством загрузки новой схемы и обработчиков. 2 н. и 9 з.п. ф-лы, 21 ил.

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

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

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

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

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

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

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

8. Способ по п.1, в котором сообщение содержит финансовую транзакцию.

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

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

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