Способ и система для управления трафиком
Иллюстрации
Показать всеИзобретение относится к технологиям сетевой связи. Технический результат заключается в повышении скорости передачи данных. Способ содержит: прием шлюзом запроса на вызов интерфейса внутреннего приложения платформы разработки приложений от клиентского приложения; получение шлюзом правил по управлению трафиком клиентского приложения или интерфейса внутреннего приложения; и обнаружение шлюзом, удовлетворяются ли правила по управлению трафиком клиентским приложением или интерфейсом внутреннего приложения; если да, то признание запроса на вызов от клиентского приложения; в противном случае отклонение запроса на вызов от клиентского приложения. 2 н. и 12 з.п. ф-лы, 3 ил.
Реферат
ОБЛАСТЬ ТЕХНИКИ
Настоящее изобретение относится к области техники коммуникационной технологии и, конкретно, к способу и системе для управления трафиком.
УРОВЕНЬ ТЕХНИКИ
Открытая платформа используется для обеспечения различных внутренних приложений для клиента. Затем клиентское приложение может использовать внутренние приложения открытой платформы, обращаясь к интерфейсу приложения открытой платформы.
Однако могут существовать перечисленные ниже проблемы, возникающие, когда внутренние приложения открытой платформы вызываются большим числом клиентских приложений.
1. Если одно и то же клиентское приложение совершает слишком многочисленные или безосновательные обращения к внутренним приложениям платформы разработки приложений, ресурсы внутренних приложений платформы разработки приложений, которые должны быть востребованы другими клиентами, могут оказаться занятыми, что может привести к дисбалансу распределения.
2. В том случае, когда одно и то же внутреннее приложение вызывается интенсивно, поскольку некоторые внутренние приложения характеризуются чрезвычайно высоким потреблением ресурсов системы, то если они будут вызываться слишком часто или безосновательно, появится тенденция к нарушению работы или даже к выходу из строя системы.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
Принимая это во внимание и учитывая отсутствие в платформе разработки приложений предшествующего уровня техники эффективного управления трафиком, осуществляемого применительно к внутренним приложениям, вызываемым клиентскими приложениями, необходимо обеспечить способ и систему для управления трафиком.
Способ для управления трафиком содержит:
прием шлюзом запроса на вызов интерфейса внутреннего приложения платформы разработки приложений от клиентского приложения;
получение шлюзом правил по управлению трафиком клиентского приложения или интерфейса внутреннего приложения;
обнаружение шлюзом, удовлетворяются ли правила по управлению трафиком клиентским приложением или интерфейсом внутреннего приложения; если да, то признание запроса на вызов от клиентского приложения; в противном случае отклонение запроса на вызов от клиентского приложения.
Система для управления трафиком, включающая в себя шлюз и модули, расположенные в шлюзе, содержит:
модуль для приема запроса на вызов, выполненный с возможностью приема запроса на вызов интерфейса внутреннего приложения платформы разработки приложений от клиентского приложения;
модуль для получения правил по управлению трафиком, выполненный с возможностью получения правил по управлению трафиком клиентского приложения или интерфейса внутреннего приложения;
модуль для обнаружения трафика, выполненный с возможностью обнаружения того, удовлетворяются ли правила по управлению трафиком клиентским приложением или интерфейсом внутреннего приложения; если да, то признание запроса на вызов от клиентского приложения; в противном случае отклонение запроса на вызов от клиентского приложения.
В настоящем изобретении посредством создания правил по управлению трафиком для интерфейса внутреннего приложения платформы разработки приложений или клиентского приложения допускается вызов интерфейса внутреннего приложения от клиентского приложения только в том случае, когда удовлетворяются правила по управлению трафиком. Правильной установкой правил по управлению трафиком осуществляется управление обращением клиентского приложения к интерфейсу внутреннего приложения и тем самым устраняется ситуация, когда внутренние приложения вызываются слишком интенсивно одним и тем же клиентским приложением через интерфейс внутреннего приложения, и вместе с тем устраняется ситуация, когда слишком интенсивно вызывается одно и то же внутреннее приложение. Поэтому потребление ресурсов системы сокращается и повышается стабильность системы.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
ФИГ. 1 - блок-схема последовательности этапов в способе управления трафиком согласно настоящему изобретению;
ФИГ. 2 - блок-схема модулей системы для управления трафиком согласно настоящему изобретению; и
ФИГ. 3 - блок-схема одного варианта осуществления системы для управления трафиком согласно настоящему изобретению.
ОПИСАНИЕ ВАРИАНТОВ ОСУЩЕСТВЛЕИЯ
Подробное описание приводится ниже в связи с прилагаемыми чертежами и конкретными вариантами осуществления.
Как показано на фиг. 1, блок-схема последовательности этапов в способе управления трафиком согласно настоящему изобретению содержит:
этап S101 - прием шлюзом запроса на вызов интерфейса внутреннего приложения платформы разработки приложений от клиентского приложения;
этап S102 - получение шлюзом правил по управлению трафиком клиентского приложения или интерфейса внутреннего приложения;
этап S103 - обнаружение шлюзом, удовлетворяются ли правила по управлению трафиком клиентским приложением или интерфейсом внутреннего приложения; если да, то признание запроса на вызов от клиентского приложения; в противном случае отклонение запроса на вызов от клиентского приложения.
Шлюз является интерфейсом, используемым для сообщения с клиентом, и запросы от клиентов принимаются через шлюз. Когда клиентскому приложению нужно обратиться к интерфейсу приложения, шлюз выполняет этап S 102 для получения соответствующих правил по управлению трафиком, причем решение по выбору правил для управления трафиком клиентского приложения или правил по управлению трафиком интерфейса внутреннего приложения, или же правил по управлению трафиком как клиентского приложения, так и интерфейса внутреннего приложения принимается шлюзом согласно профилю. На этапе S102 шлюз получает правила по управлению трафиком клиентского приложения или интерфейса внутреннего приложения, и этот этап содержит три следующих случая:
случай I: получение правил по управлению трафиком клиентского приложения;
случай II: получение правил по управлению трафиком интерфейса внутреннего приложения;
случай III: получение правил по управлению трафиком клиентского приложения и интерфейса внутреннего приложения.
В одном из вариантов осуществления правила по управлению трафиком являются следующими:
в течение периода времени для подсчета вызовов заданного приложения, если число раз, когда клиентское приложение совершает вызов, не превышает верхнего порогового значения для вызова приложения, соответствующего клиентскому приложению, правила по управлению трафиком удовлетворяются; в противном случае правила по управлению трафиком не удовлетворяются; или
в течение периода времени для подсчета вызовов заданного интерфейса приложения, если число раз, когда вызывается интерфейс внутреннего приложения, превышает пороговое значение для интерфейса приложения, соответствующего интерфейсу внутреннего приложения, правила по управлению трафиком удовлетворяются; в противном случае правила по управлению трафиком не удовлетворяются; или
в течение периода времени для подсчета вызовов интерфейса внутреннего приложения от заданного клиентского приложения, если число раз, когда клиентское приложение вызывает интерфейс внутреннего приложения, не превышает верхнего порогового значения для совместного вызова, соответствующего как клиентскому приложению, так и интерфейсу внутреннего приложения, правила по управлению трафиком удовлетворяются; в противном случае правила по управлению трафиком не удовлетворяются.
Этот вариант осуществления содержит три вида правил по управлению трафиком, и шлюз способен выбирать сочетание одного или более из этих правил по отношению к разным клиентским приложениям и разным интерфейсам внутренних приложений согласно профилю.
Например, для клиентского приложения A, вызывающего интерфейс B приложения, могут быть выбраны следующие правила по управлению трафиком:
в течение периода времени для подсчета вызовов заданного приложения, если число раз, когда клиентское приложение совершает вызов, не превышает верхнего порогового значения для вызова приложения, соответствующего клиентскому приложению, правила по управлению трафиком удовлетворяются; в противном случае правила по управлению трафиком не удовлетворяются.
При этом ограничиваются только вызовы от клиентского приложения, но интерфейс приложения не ограничивается.
Альтернативно правила по управлению трафиком могут быть выбраны следующими:
в течение периода времени для подсчета вызовов заданного интерфейса приложения, если число вызовов интерфейса внутреннего приложения превышает пороговое значение для интерфейса приложения, соответствующего интерфейсу внутреннего приложения, правила по управлению трафиком удовлетворяются; в противном случае правила по управлению трафиком не удовлетворяются.
При этом ограничиваются только вызовы интерфейса приложения, но клиентское приложение не ограничивается.
Кроме того, правила по управлению трафиком могут быть также выбраны как сочетание двух упомянутых выше видов правил по управлению трафиком, то есть производится ограничение трафика не только на вызовы от клиентского приложения, но вводится ограничение также и на вызовы интерфейса приложения.
Более конкретно, ограничение на вызовы заданного интерфейса приложения от заданного клиентского приложения, то есть правило по управлению трафиком, является следующим:
в течение периода времени для подсчета вызовов интерфейса внутреннего приложения от заданного клиентского приложения, если число вызовов интерфейса внутреннего приложения от клиентского приложения не превышает верхнего порогового значения для совместного вызова, соответствующего как клиентскому приложению, так и интерфейсу внутреннего приложения, правило по управлению трафиком удовлетворяется; в противном случае правило по управлению трафиком не удовлетворяется.
Что касается периода времени для подсчета вызовов заданного приложения, то период времени для подсчета вызовов заданного интерфейса приложения и период времени для подсчета вызовов интерфейса внутреннего приложения от заданного клиентского приложения могут быть одним и тем же или разными, и период времени может выбираться в соответствии с практическим требованием, таким как один день, один час или одна минута.
Один из вариантов осуществления дополнительно содержит:
получение системой контролируемого анализа, которая связана со шлюзом, числа раз, когда клиентское приложение совершает вызов, посредством обращения к журналу регистрации доступа к шлюзу, и если в течение периода времени для подсчета вызовов заданного приложения обнаружится, что число раз когда, клиентское приложение совершает вызов, превышает порог предупреждения для вызова приложения, соответствующего клиентскому приложению, приобретается электронный адрес контактного лица клиентского приложения, и предупреждающее электронное сообщение посылается на электронный адрес контактного лица, причем порог предупреждения для вызова приложения меньше или равен верхнему пороговому значению для вызова приложения, или
получение системой контролируемого анализа, которая связана со шлюзом, числа раз, когда клиентское приложение совершает вызов, посредством обращения к журналу регистрации доступа к шлюзу, и если в течение периода времени для подсчета вызовов интерфейса внутреннего приложения от заданного клиентского приложения обнаружится, что число вызовов клиентским приложением интерфейса внутреннего приложения превышает порог предупреждения для совместного вызова, соответствующего как клиентскому приложению, так и интерфейсу внутреннего приложения, приобретается электронный адрес контактного лица клиентского приложения, и предупреждающее электронное сообщение посылается на электронный адрес контактного лица, причем порог предупреждения для совместного вызова меньше или равен верхнему пороговому значению для совместного вызова.
В этом варианте осуществления, если число раз, когда клиентское приложение совершает вызов, или число раз, когда клиентское приложение вызывает интерфейс внутреннего приложения, превышает порог предупреждения, предупреждающее электронное сообщение посылается контактному лицу клиентского приложения. Затем, если контактное лицо решит увеличить пороговое значение по мере необходимости, подтверждение запроса на увеличение может быть послано в шлюз и пороговое значение соответствующим образом увеличится. В этом варианте осуществления пороговое значение может быть увеличено для клиентского приложения по мере необходимости.
Один из вариантов осуществления дополнительно содержит:
получение системой контролируемого анализа, которая связана со шлюзом, числа раз, когда клиентское приложение совершает вызов, посредством обращения к журналу регистрации доступа к шлюзу, и вычисление оценочного числа раз, когда клиентское приложение совершает вызов в течение периода времени, для оценки будущих приращений; если оценочное число совершения вызовов превышает верхнее пороговое значение для вызова приложения, связанного с клиентским приложением, верхнее пороговое значение для вызова приложения сохраняется как верхнее пороговое значение в истории вызовов приложения, идентификация программы для клиентского приложения принимается за идентификацию приложения, подлежащего обновлению, оценочное число вызовов принимается за верхнее пороговое значение для вызовов приложения, подлежащего обновлению, посылается запрос на обновление верхнего порогового значения для вызова приложения, который включает в себя верхнее пороговое значение для вызова приложения, подлежащего обновлению, и идентификацию соответствующего приложения, подлежащего обновлению; затем, по истечении времени для оценки приращения, если подтверждение запроса на увеличение верхнего порогового значения для вызова приложения не принято, верхнее пороговое значение из истории вызовов приложения принимается за верхнее пороговое значение для вызова приложения, подлежащего обновлению, и затем посылается упомянутый запрос на обновление верхнего порогового значения для вызова приложения;
если упомянутый запрос на обновление верхнего порогового значения для вызова приложения, посланный от системы контролируемого анализа, принят шлюзом, верхнее пороговое значение для вызова приложения, связанного с идентификацией приложения, подлежащего обновлению, обновляется как упомянутое верхнее пороговое значение для вызова приложения, подлежащего обновлению;
если подтверждение запроса на увеличение верхнего порогового значения для вызова приложения принято шлюзом, запрос передается в систему контролируемого анализа.
Система контролируемого анализа, которая связана со шлюзом, получает число раз, когда клиентское приложение совершает вызов, посредством обращения к журналу регистрации доступа к шлюзу, и вычисляет оценочное число раз, когда клиентское приложение совершает вызов в течение периода времени, для оценки будущего приращения. Когда находится, что оценочное число совершения вызовов превышает пороговое значение для вызовов от приложения, запрос на обновление верхнего порогового значения для вызовов от приложения посылается в шлюз и приращение верхнего порогового значения для вызовов от приложения приводится в состояние ожидания. Тем самым может быть устранена ситуация, при которой клиентское приложение становится недоступным вследствие достижения верхнего предела. Однако приращение верхнего порогового значения не является неограниченным. Клиентскому приложению необходимо посылать подтверждение запроса на увеличение верхнего порогового значения для вызова приложения в течение периода времени, в противном случае верхнее пороговое значение для вызовов от приложения будет переустановлено на сохраненное исходное пороговое значение, и, таким образом, вызовы от клиентского приложения будут ограничены.
Один из вариантов осуществления дополнительно содержит:
получение системой контролируемого анализа, которая связана со шлюзом, числа раз, когда клиентское приложение вызывает интерфейс внутреннего приложения, посредством обращения к журналу регистрации доступа к шлюзу, и вычисление оценочного числа раз, когда клиентское приложение вызывает интерфейс внутреннего приложения в течение периода времени, для оценки будущего приращения; если оценочное число совершения вызовов превышает заданное верхнее пороговое значение для совместного вызова, связанного с клиентским приложением, верхнее пороговое значение для совместного вызова запоминается как верхнее пороговое значение для совместного вызова, идентификация программы для клиентского приложения принимается за идентификацию приложения, подлежащего обновлению, оценочное число вызовов принимается за верхнее пороговое значение для совместного вызова, посылается запрос на обновление верхнего порогового значения для совместного вызова, который включает в себя верхнее пороговое значение для совместного вызова, подлежащее обновлению, и идентификацию соответствующего приложения, подлежащего обновлению; затем, по истечении времени для оценки приращения, если подтверждение запроса на увеличение верхнего порогового значения для совместного вызова не получено, верхнее пороговое значение из истории совместного вызова принимается за верхнее пороговое значение для совместного вызова, подлежащее обновлению, и затем посылается упомянутый запрос на обновление верхнего порогового значения для совместного вызова;
если упомянутый запрос на обновление верхнего порогового значения для совместного вызова, посланный от системы контролируемого анализа, принят шлюзом, верхнее пороговое значение для совместного вызова, связанное с идентификацией приложения, подлежащего обновлению, обновляется как упомянутое верхнее пороговое значение для совместного вызова, подлежащее обновлению;
если подтверждение запроса на увеличение верхнего порогового значения для совместного вызова принято шлюзом, запрос передается в систему контролируемого анализа.
В одном из вариантов осуществления,
когда запрос на вызов клиентского приложения признается шлюзом, число совершения вызовов клиентским приложением возрастает и число вызовов интерфейса внутреннего приложения возрастает, число раз, когда клиентское приложение вызывает интерфейс внутреннего приложения, возрастает, и эти увеличенные числа раз посылаются в счетчик кластеров, который связан со шлюзом;
когда шлюз обнаруживает, удовлетворяет ли клиентское приложение или интерфейс внутреннего приложения правилам по управлению трафиком, получение от счетчика кластеров:
числа раз, когда клиентское приложение совершает вызов в течение периода времени, для подсчета вызовов заданного приложения;
числа раз, когда вызывается интерфейс внутреннего приложения в течение периода времени, для подсчета вызовов заданного интерфейса приложения; или
числа раз, когда клиентское приложение вызывает интерфейс внутреннего приложения в течение периода времени, для подсчета вызовов интерфейса внутреннего приложения от заданного клиентского приложения.
Число раз, когда клиентское приложение совершает вызов, число раз, когда вызывается интерфейс внутреннего приложения, и число раз, когда клиентское приложение обращается к интерфейсу внутреннего приложения, сохраняются счетчиком кластеров, который может снизить рабочую нагрузку шлюза.
Один из вариантов осуществления дополнительно содержит:
выделение шлюзом по меньшей мере одного потока интерфейсу приложения и установку его как бездействующего потока;
если запрос на вызов клиентского приложения признается шлюзом, обнаружение, имеет ли интерфейс внутреннего приложения бездействующий поток;
если интерфейс внутреннего приложения имеет по меньшей мере один бездействующий поток, выбор одного потока из бездействующих потоков интерфейса внутреннего приложения в качестве текущего потока, интерфейс внутреннего приложения вызывается клиентским приложением, используя текущий поток, и текущий поток устанавливается в качестве рабочего потока; когда клиентское приложение заканчивает вызов интерфейса внутреннего приложения, текущий поток устанавливается как бездействующий поток;
если интерфейс внутреннего приложения не имеет бездействующего потока, перевод в состояние ожидания запроса на вызов клиентского приложения до тех пор, пока интерфейс внутреннего приложения не буде иметь по меньшей мере один бездействующий поток.
В соответствии с этим интерфейс внутреннего приложения может быть ограничен потоками, тем самым большое число параллельных вызовов одного и того же интерфейса внутреннего приложения может быть исключено.
На фиг. 2 представлена блок-схема модулей системы управления трафиком согласно настоящему изобретению, которая содержит шлюз 21 и модули, расположенные в шлюзе 21, которые содержат:
модуль 2110 для приема запроса на вызов, выполненный с возможностью приема запроса на вызов интерфейса внутреннего приложения платформы разработки приложений от клиентского приложения;
модуль 2102 для получения правил по управлению трафиком, выполненный с возможностью получения правил по управлению трафиком клиентского приложения или интерфейса внутреннего приложения;
модуль 2103 для обнаружения трафика, выполненный с возможностью обнаружения, удовлетворяются ли правила по управлению трафиком клиентским приложением или интерфейсом внутреннего приложения; если да, то признание запроса на вызов от клиентского приложения; в противном случае отклонение запроса на вызов от клиентского приложения.
В одном из вариантов осуществления правила по управлению трафиком являются следующими:
в течение периода времени для подсчета вызовов заданного приложения, если число раз, когда клиентское приложение совершает вызов, не превышает верхнего порогового значения для вызова приложения, соответствующего клиентскому приложению, правила по управлению трафиком удовлетворяются; в противном случае правила по управлению трафиком не удовлетворяются; или
в течение периода времени для подсчета вызовов интерфейса внутреннего приложения, если число раз, когда вызывается интерфейс внутреннего приложения, превышает пороговое значение для интерфейса приложения, соответствующего интерфейсу внутреннего приложения, правила по управлению трафиком удовлетворяются; в противном случае правила по управлению трафиком не удовлетворяются; или
в течение периода времени для подсчета вызовов интерфейса внутреннего приложения от заданного клиентского положения, если число раз, когда клиентское приложение вызывает интерфейс внутреннего приложения, не превышает верхнего порогового значения для совместного вызова, соответствующего как клиентскому приложению, так и интерфейсу внутреннего приложения, правила по управлению трафиком удовлетворяются; в противном случае правила по управлению трафиком не удовлетворяются.
Один из вариантов осуществления дополнительно содержит систему 22 контролируемого анализа, которая связана со шлюзом, и
предупреждающий модуль 221 трафика, расположенный в системе 22 контролируемого анализа, выполненный с возможностью получения числа раз, когда клиентское приложение совершает вызов, посредством обращения к журналу регистрации доступа к шлюзу, и если в течение периода времени для подсчеты вызовов заданного приложения обнаруживается, что число раз, когда клиентское приложение совершает вызов, превышает порог предупреждения для вызовов приложения, соответствующего клиентскому приложению, приобретается электронный адрес контактного лица клиентского приложения, и тревожное электронное сообщение посылается по электронному адресу контактного лица, причем порог предупреждения для вызова приложения меньше или равен верхнему пороговому значению для вызова приложения; или
получение числа раз, когда клиентское приложение совершает вызов, посредством обращения к журналу регистрации доступа к шлюзу, и если в течение периода времени для подсчета вызовов интерфейса внутреннего приложения от заданного клиентского приложения обнаруживается, что число раз, когда клиентское приложение вызывает интерфейс внутреннего приложения, превышает порог предупреждения для совместного вызова, соответствующего как клиентскому приложению, так интерфейсу внутреннего приложения, приобретается электронный адрес контактного лица клиентского приложения, и предупреждающее сообщение посылается по электронному адресу контактного лица, причем порог предупреждения для совместного вызова меньше или равен верхнему пороговому значению для совместного вызова.
Один из вариантов осуществления дополнительно содержит систему 22 контролируемого анализа, которая связана со шлюзом, и
модуль 222 для посылки запроса на обновление верхнего порогового значения для вызова приложения, расположенный в системе 22 контролируемого анализа и выполненный с возможностью получения числа раз, когда клиентское приложение совершает вызов, посредством обращения к журналу регистрации доступа к шлюзу, и вычисления оценочного числа раз, когда клиентское приложение совершает вызов в течение периода времени, для оценки будущего приращения; если оценочное число раз совершения вызовов превышает верхнее пороговое значение для вызова приложения, связанного с клиентским приложением, верхнее пороговое значение для вызова приложения сохраняется как верхнее пороговое значение в истории вызовов приложения, идентификация программы клиентского приложения принимается за идентификацию приложения, подлежащего обновлению, оценочное число раз совершения вызовов принимается за верхнее пороговое значение для вызова приложения, подлежащего обновлению, посылается запрос на обновление верхнего порогового значения для вызова приложения, который включает в себя верхнее пороговое значение для вызова приложения, подлежащего изменению, и идентификацию соответствующего приложения, подлежащего изменению; затем, по истечении периода времени для оценки приращения, если подтверждение запроса на увеличение верхнего порогового значения для вызова приложения не принято, верхнее пороговое значение из истории вызовов приложения принимается за верхнее пороговое значение для вызова приложения, подлежащего изменению, и затем посылается упомянутый запрос на обновление верхнего порогового значения для вызова приложения;
модуль 2104 для приема запроса на обновление верхнего порогового значения для вызова приложения, расположенный в системе контролируемого анализа и выполненный с возможностью приема упомянутого запроса на обновление верхнего порогового значения для вызова приложения, посланного от системы контролируемого анализа, и обновления верхнего порогового значения для вызова приложения, связанного с идентификацией приложения, подлежащего обновлению, как упомянутого верхнего порогового значения для вызова приложения, подлежащего обновлению;
модуль 2105 для приема подтверждения запроса на увеличение верхнего порогового значения для вызова приложения, расположенный в шлюзе 21 и выполненный с возможностью передачи принятого подтверждения запроса на увеличение верхнего порогового значения для вызова приложения в систему контролируемого анализа.
Один из вариантов осуществления дополнительно содержит систему 22 контролируемого анализа, которая связана со шлюзом, и
модуль 223 для посылки запроса на обновление верхнего порогового значения для совместного вызова, расположенный в системе 22 контролируемого анализа и выполненный с возможностью получения числа раз, когда клиентское приложение вызывает интерфейс внутреннего приложения, посредством обращения к журналу регистрации доступа к шлюзу, и вычисления оценочного числа раз, когда клиентское приложение вызывает интерфейс внутреннего приложения в течение периода времени, для оценки будущего приращения; если оценочное число совершения вызовов превышает заданное верхнее пороговое значение для совместного вызова, связанного с клиентским приложением, верхнее пороговое значение для совместного вызова сохраняется как верхнее пороговое значение для совместного вызова, идентификация программы клиентского приложения принимается за идентификацию приложения, подлежащего обновлению, оценочное число совершения вызовов принимается за верхнее пороговое значение для совместного вызова, посылается запрос на обновление верхнего порогового значения, который включает в себя верхнее пороговое значение для совместного вызова, подлежащее обновлению, и идентификацию соответствующего приложения, подлежащего обновлению; затем, по истечении периода времени для оценки приращения, если подтверждение запроса на увеличение верхнего порогового значения для совместного вызова не принято, верхнее пороговое значение из истории совместного вызова принимается за верхнее пороговое значение для совместного вызова, подлежащее изменению, и затем посылается упомянутый запрос на обновление верхнего порогового значения для совместного вызова;
модуль 2106 для приема запроса на обновление верхнего порогового значения для совместного вызова, расположенный в шлюзе 21 и выполненный с возможностью приема упомянутого запроса на обновление верхнего порогового значения для совместного вызова, посланного от системы контролируемого анализа, и обновления верхнего порогового значения для совместного вызова, связанного с идентификацией приложения, подлежащего обновлению, как упомянутого верхнего порогового значения для совместного вызова, подлежащего обновлению;
модуль 2107 для приема подтверждения запроса на увеличение верхнего порогового значения для совместного вызова, расположенный в шлюзе 21 и выполненный с возможностью передачи принятого подтверждения запроса на увеличение верхнего порогового значения для совместного вызова в систему контролируемого анализа.
Один из вариантов осуществления дополнительно содержит:
модуль 2108 для посылки числа совершения вызовов, расположенный в шлюзе 21 и выполненный с возможностью того, что когда запрос на вызов клиентского приложения признан, число совершения вызовов клиентским приложением возрастает и число вызовов интерфейса внутреннего приложения возрастает, число раз, когда клиентское приложение вызывает интерфейс внутреннего приложения, возрастает, и эти увеличенные числа раз посылаются в счетчик 23 кластеров, который связан со шлюзом;
модуль 2103 обнаружения трафика, расположенный в шлюзе 21 и выполненный с возможностью, когда он обнаруживает, удовлетворяет ли клиентское приложение или интерфейс внутреннего приложения правилам управления трафиком, получать от счетчика кластеров:
число раз, когда клиентское приложение совершает вызов в течение периода времени, для подсчета вызовов заданного приложения, или
число раз, когда интерфейс внутреннего приложения вызывается в течение периода времени, для подсчета вызовов заданного интерфейса приложения, или
число раз, когда клиентское приложение вызывает интерфейс внутреннего приложения в течение периода времени, для подсчета вызовов интерфейса внутреннего приложения от заданного клиентского приложения.
Один из вариантов осуществления дополнительно содержит:
модуль 2109 выделения потоков, расположенный в шлюзе 21 и выполненный с возможностью выделения по меньшей мере одного потока интерфейсу приложения и установки по меньшей мере одного потока в качестве бездействующего потока;
модуль 2110 обнаружения потока, расположенный в шлюзе 21 и выполненный с возможностью обнаружения, имеет ли интерфейс внутреннего приложения бездействующий поток, и если запрос на вызов клиентского приложения признан:
если интерфейс внутреннего приложения имеет по меньшей мере один бездействующий поток, выбор одного потока из бездействующих потоков интерфейса внутреннего приложения в качестве текущего потока, интерфейс внутреннего приложения вызывается клиентским приложением, используя текущий поток, и текущий поток устанавливается как рабочий поток; когда клиентское приложение завершает обращение к интерфейсу внутреннего приложения, текущий поток устанавливается как бездействующий поток;
если интерфейс внутреннего приложения не имеет бездействующего потока, запрос на вызов клиентского приложения переводится в состояние ожидания до тех пор, пока интерфейс внутреннего приложения не будет иметь по меньшей мере один бездействующий поток.
На фиг. 3 представлена блок-схема одного примера системы управления трафиком согласно настоящему изобретению. Система содержит шлюз 31, распределенный центральный счетчик 32, систему 33 анализа регистрационных данных, систему 34 управления транзакциями.
При этом в шлюзе 31 обеспечен пул 331 контролируемого размера трафика, который выделен в управлении трафиком для вызова интерфейса внутреннего приложения от клиентского приложения. Распределенный центральный счетчик 32 используется для запоминания числа раз, когда клиентское приложение совершает вызов, числа раз, когда вызывается интерфейс внутреннего приложения, и числа раз, когда клиентское приложение обращается к интерфейсу внутреннего приложения.
При этом система 33 анализа регистрационных данных и система 34 управления транзакциями совместно образуют вышеупомянутую систему контролируемого анализа. Система 33 анализа регистрационных данных получает регистрационные данные от шлюза 31 для анализа и вычисляет, превышает ли число раз, когда клиентское приложение совершало вызов, порог предупреждения для вызова приложения, соответствующего клиентскому приложению, в течение периода времени, для подсчета вызовов заданного приложения, или превышает ли число раз, когда клиентское приложение вызывало интерфейс внутреннего приложения, порог предупреждения для совместного вызова, соответствующего как клиентскому приложению, так и интерфейсу внутреннего приложения, в течение периода времени, для подсчета вызовов интерфейса внутреннего приложения от заданного клиентского приложения. Если да, то это извещает систему 34 управления транзакциями о посылке предупреждающего электронного сообщения. При этом период времени для подсчета вызовов заданного приложения и период времени для подсчета вызовов интерфейса внутреннего приложения от заданного клиентского приложения устанавливаются равными одному дню.
Между тем система 33 анализа регистрационных данных получает число раз, когда клиентское приложение совершает вызов, и вычисляет оценочное число раз, когда клиентское приложение совершает вызов в течение периода времени, для оценки будущего приращения; получает число раз, когда клиентское приложение вызывает интерфейс внутреннего приложения, и вычисляет оценочное число раз, когда клиентское приложение вызывает интерфейс внутреннего приложения в течение периода времени, для оценки будущего приращения. Затем система 34 управления транзакциями решает, нужно ли посылать в шлюз 31 запрос на обновление верхнего порогового значения для вызовов приложения и запрос на обновление верхнего порогового значения для совместного вызова, основываясь на результатах вычислений, произведенных системой 33 анализа регистрационных данных. Период времени для оценки приращения предпочтительно устанавливается равным трем дням.
В соответствии с этим, если число вызовов от клиентского приложения превышает порог предупреждения для вызовов приложения, соответствующего клиентскому приложению, или если число раз, когда клиентское приложение вызывает внутреннее приложение, превышает порог предупреждения для совместного вызова, соответствующего как клиентскому приложению, так и интерфейсу внутреннего приложения, будет послано предупреждающее электронное сообщение. Кроме того, подсчитываются оценочное число совершения вызовов в течение периода времени для оцени будущего приращения и оценочное число раз, когда клиентское приложение в