forum.bitel.ru
http://forum.bitel.ru/

Единый API для всех приложений биллинга
http://forum.bitel.ru/viewtopic.php?f=1&t=4596		 Страница 1 из 1
Автор:  Администратор [ 28 сен 2010, 18:17 ]
Заголовок сообщения:  Единый API для всех приложений биллинга
Собственно проблема возникла в этой ветке.
viewtopic.php?f=5&t=4027&p=28135

Вызвана использованием в скриптах BGBS BGBilling API отличных от DialUp модулей.
Как способ решения - единый набор BGBilling API библиотек для всех приложений биллинга.

Как планируется реализовать:
1) Библиотеки сервера биллинга разделяются на:
lib
+ ext - внешние
+ app - BGBilling API

2) Процесс обновления биллинга не отличается от текущего. Обновление с FTP сайта, только в библиотеку kernel будут включены в т.ч. поддержка всех RADIUS, NetFlow и т.п. протоколов.

3) Все сторонние компоненты биллинга имеют следующую структуру каталогов библиотек.
lib
+ ext - внешние, состав библиотек существенно меньше чем у сервера
+ app - BGBilling API
lib.app.update - в этот каталог складываются обвновлённые библиотеки.

4) После обновления сервера биллинга следует вызвать утилиту bg_installer.sh update для каждого из сторонних приложений .
При этом стороннее приложение обращается к серверу по JMS протоколу и сравнивает свои lib/app библиотеки с библиотеками сервера.
Полученные новые библиотеки складываются в lib.app.update и будут перемещены в lib/app при следующем рестарте приложения.

5) У каждого приложения реализовать аларм, периодически проверяющий библиотеки сервера на возможность своего обновления и напоминающий администратору о сей необходимости.
А может пусть вытягивает апдейты автоматом в lib.app.update и пишет о необходимости ребута.

Сложности:
1) Библиотека kernel.jar будет меняться достаточно часто, что будет требовать рестарта например радиуса.
Хотя реально в ней может изменится какой-то только веб сервис, радиусу и не нужный.
Возможно стоит разделить API и акшены/веб сервисы. Хотя излишнее деление усложнит сборку и публикацию обновлений.

Это же, хотя и в меньшей мере относится к dialup.jar, из которого также можно вычленить акшены.

2) Если внешнее приложение постоянно будет требовать всего состава библиотек, опять же придётся его рестартовать по каждому обновлению любого модуля.
Возможно в штатной поставке стоит поставлять только, например kernel.jar, dialup.jar а необходимые скриптам библиотеки сначала вручную скопировать в lib.app
с последующим автоматическим обновлением.

Преимущества:
1) Работа скрипта в контексте любого приложения биллинга.
2) Возможность отправки событий радиуса на обработку, например, серверу. Т.к. классы везде будут единые.
Автор:  skyb [ 28 сен 2010, 19:12 ]
Заголовок сообщения:  Re: Единое API для всех приложений биллинга
Цитата:
2) Если внешнее приложение постоянно будет требовать всего состава библиотек, опять же придётся его рестартовать по каждому обновлению любого модуля.

так сделали же то что при меняние конфига радиуса рестарт ненужн...неполуится сделать так же и с этим???
Цитата:
2) Возможность отправки событий радиуса на обработку, например, серверу. Т.к. классы везде будут единые.

А если всетаки посмотреть в сторону activmq ??
Автор:  Cromeshnic [ 29 сен 2010, 06:42 ]
Заголовок сообщения:  Re: Единое API для всех приложений биллинга
Администратор писал(а):
5) У каждого приложения реализовать аларм, периодически проверяющий библиотеки сервера на возможность своего обновления и напоминающий администратору о сей необходимости.
А может пусть вытягивает апдейты автоматом в lib.app.update и пишет о необходимости ребута.

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

Администратор писал(а):
библиотеку kernel будут включены в т.ч. поддержка всех RADIUS, NetFlow и т.п. протоколов.

O_o

Администратор писал(а):
1) Работа скрипта в контексте любого приложения биллинга.

А оно нужно? Логичнее всё-таки все асинхронные скрипты исполнять в одном месте, передавая их через ActiveMQ. А синхронные нагружать внешней логикой как-то неправильно.

Администратор писал(а):
2) Возможность отправки событий радиуса на обработку, например, серверу. Т.к. классы везде будут единые.

Может лучше иметь единый универсальный формат сообщений JMS для событий, чем классы?
Автор:  Cromeshnic [ 29 сен 2010, 06:57 ]
Заголовок сообщения:  Re: Единое API для всех приложений биллинга
Я всё-таки сторонник модульности. Бывает велик соблазн объединить всё в одну кучу, но если он возникает, то что-то идёт не так.
Автор:  Администратор [ 29 сен 2010, 10:10 ]
Заголовок сообщения:  Re: Единое API для всех приложений биллинга
Цитата:
А оно нужно? Логичнее всё-таки все асинхронные скрипты исполнять в одном месте, передавая их через ActiveMQ. А синхронные нагружать внешней логикой как-то неправильно.

В том же событии "Открытие учётного периода" у snark а возникла потребность управления абонплатой. Логика не внешняя, она вся в контексте биллинга.

Цитата:
Может лучше иметь единый универсальный формат сообщений JMS для событий, чем классы?

Фразу не понял.

Цитата:
Я всё-таки сторонник модульности. Бывает велик соблазн объединить всё в одну кучу, но если он возникает, то что-то идёт не так.

Ну модульности тут не убудет :) Просто эта модульность будет для всех приложений, не только сервера. Сейчас радиус фактически монолит.
Автор:  Cromeshnic [ 29 сен 2010, 10:23 ]
Заголовок сообщения:  Re: Единое API для всех приложений биллинга
Имхо логичнее радиусу только сигнализировать через JMS о том, что событие произошло, а затем уже на стороне сервера исполнится скрипт, который это событие отработает. Почему радиус должен знать что-то об абонплатах и т.п. не относящихся к нему вещах?
Автор:  snark [ 01 окт 2010, 09:50 ]
Заголовок сообщения:  Re: Единое API для всех приложений биллинга
вставлю свои 5 копеек ...
скрипты, как верно заметил Администратор, пишутся в контексте биллинга и видимость классов в рамках биллинга должна быть полной (о чем собсно и тред), иначе получается катавасия - вот тут класс вроде бы есть, но вот тут его использовать нельзя :( события - это по сути свисток арбитра, по которому матч начинается и при этом по свистку игроки (классы) должны иметь право двигаться по всему полю ;)
Автор:  Cromeshnic [ 01 окт 2010, 10:47 ]
Заголовок сообщения:  Re: Единое API для всех приложений биллинга
"В контексте биллинга", ага. Контекст радиуса - это не контекст биллинга. Приведите пример синхронного события радиуса, требующего логики из контекста биллинга?

Я бы предпочёл, чтобы по свистку (который слышат все), каждый игрок начал делать свою работу в своём углу, вместо того, чтобы создавать броуновское движение.
Автор:  Cromeshnic [ 01 окт 2010, 10:54 ]
Заголовок сообщения:  Re: Единое API для всех приложений биллинга
snark писал(а):
вставлю свои 5 копеек ...
скрипты, как верно заметил Администратор, пишутся в контексте биллинга

Так пусть и исполняются они в контексте биллинга, а не в разных приложениях с общими либами. Кроме тех, которые непосредственно относятся к функциональности этих приложений.
Автор:  snark [ 01 окт 2010, 11:23 ]
Заголовок сообщения:  Re: Единое API для всех приложений биллинга
да елки палки! RADIUS - это тоже биллинг, это его (БГБ) часть, лично для меня - одна из важнейших, и лично мне абсолютно всеравно в каком именно контексте выполянется тот или иной скрипт - он выполянется в биллинге, который для меня состоит из dialup и npay (ipn для детализации не в счет) модулей связанных между собой сервером - все! это и есть "биллинг" для меня, для кого-то набор модулей будет иным, но суть практически (за редким исключением) всегда останется той же - некий модуль или их набор будет заниматься обсчетом денег, т.е., в широком смысле слова биллингом, а скрипты пишутся для того чтобы оный биллинг, т.е. та самая считалка, работала так, как того требуют обстоятельства и, повторюсь, контекст в котором выполняются скрипты тут совершенно не важен! важно чтобы классы виделись и скрипты выполнялись вне зависимости от того к какой именно части биллинга они относятся, важна не работа системы по частям, а работа ее в целом, IMHO
Автор:  Cromeshnic [ 01 окт 2010, 11:41 ]
Заголовок сообщения:  Re: Единое API для всех приложений биллинга
Да ёлки палки! Этого можно добиться более архитектурно "красивым" способом, нежели подсовывать библиотеки npay и пр. радиусу.
1) Все асинхронные события радиус отправляет в ActiveMQ.
2) Все синхронные события исполняются в контексте радиуса
3) Если возникает нужда в библиотеке npay в синхронном событии радиуса, то у вас что-то архитектурно неправильно задумано.

1) Асинхронные события выгребаются сервером биллинга и исполняются в его контексте. AFAIK, Если дополнительно сконфигурить ActiveMQ, можно подписаться на эти события вообще любым приложением => profit!
2) 3) Радиус должен работать быстро и просто. Поэтому синхронные события по максимуму не должны использовать внешние вызовы, бизнес-логику и прочую сложную логику.
Автор:  vdd [ 01 окт 2010, 11:53 ]
Заголовок сообщения:  Re: Единое API для всех приложений биллинга
Cromeshnic писал(а):
3) Если возникает нужда в библиотеке npay в синхронном событии радиуса, то у вас что-то архитектурно неправильно задумано.

Да ладно вам. Может человеку аппаратная часть позволяет почасовой прогноз погоды на месяц рассчитывать по каждому пакету радиуса. Делал же тут кто-то реалтайм маршрутизацию VoIP посредством запросов в тарифные планы.
Припрет - спроксирует/скеширует с помощью того же Радиатора.
Автор:  Cromeshnic [ 01 окт 2010, 11:58 ]
Заголовок сообщения:  Re: Единое API для всех приложений биллинга
Ну вот запросы в тарифные планы - это стандартный функционал BGRadiusDialup.

Да, иногда приходится костыли делать. Но делать костыли на уровне разработчиков - неправильно.
Автор:  focus [ 01 окт 2010, 12:11 ]
Заголовок сообщения:  Re: Единое API для всех приложений биллинга
Ребята, скажите зачем вы хотите использовать ActiveMQ в биллинге ?
Какую Вы цель перед собой ставите ?
Какие проблемы вы хотите решить с помощью ActiveMQ ?

По сути если использовать шину JMS, то можно взаимодействия компонентов БГ (радиус, ядро и.т.д) обеспечить за счет событий.
Обмениваться событиями (сообщениями) с помощью ActiveMQ.
Далее уже, как писал Cromeshnic
Цитата:
Если дополнительно сконфигурить ActiveMQ, можно подписаться на эти события вообще любым приложением => profit!

Т.е если Вам нужно будет выполнить какой-либо скрипт при определенном событии в радиусе (а это определенное сообщение в ActiveMQ) - то можно просто дополнительно своим листнером слушать topic и при определенных сообщениях выполнять свою логику.
Автор:  snark [ 01 окт 2010, 12:25 ]
Заголовок сообщения:  Re: Единое API для всех приложений биллинга
Cromeshnic писал(а):
Этого можно добиться более архитектурно "красивым" способом, нежели подсовывать библиотеки npay и пр. радиусу.

это где это я в этой ветке писал и/или предлагал делать подобное?

Cromeshnic писал(а):
Если возникает нужда в библиотеке npay в синхронном событии радиуса, то у вас что-то архитектурно неправильно задумано.

тут речь в первую очередь о том что все компоненты системы _обязаны_ иметь доступ к классам друг друга! например в моем конкретном случае - dialup ранее видел классы npay, а потом, после обновления, пререстал их видеть - я об этом написал, обсудили, пришли к выводу что да, это не есть гут, оттуда и родилась эта тема ...
вкратце - тема родилась потому что БГБ движется вперед и хочет сохранить все то хорошее что в нем есть, а не потому что я каким либо образом нагибаю разработчиков или как Вы изволили выразится - делаю костыли на их уровне ...

Cromeshnic писал(а):
Радиус должен работать быстро и просто.

у меня радиус работает и быстро и при этом до одурения просто (логика работы проста как мычание), может поэтому система которая "архитектурно неправильна задумана"(с) не заставляет меня задаваться вопросами статусов и прочими очень популярными тут, в обсуждениях, сентенциями? я изначально все архитектурно так неправильно задумал что все работает уже несколько лет без сбоев и косяки изредка вылазят только когда надо обновится, но я это быстро решаю и корабль плывет дальше :)
Автор:  Администратор [ 01 окт 2010, 12:29 ]
Заголовок сообщения:  Re: Единое API для всех приложений биллинга
Цитата:
Имхо логичнее радиусу только сигнализировать через JMS о том, что событие произошло, а затем уже на стороне сервера исполнится скрипт, который это событие отработает. Почему радиус должен знать что-то об абонплатах и т.п. не относящихся к нему вещах?

Проблему можно решить, дав возможность отправлять событие из скрипта уже серверу.
Т.е. работает, например, синхронное _локальное_ событие. У него есть RADIUS пакет, объект соединения.
Предположим, что там нужно что-то поменять в зависимости от наличия абонплаты.
Скрипт обработки локального синхронного события шлёт свой запрос-событие ядру, получает ответ и модифицирует, например, соединение.
Проблема в том, что в этом случае нужно где-то дать возможность определять эти классы-события. Или костыльно слать просто строковые сообщения, парсить их там и обрабатывать.
Передавать же объект "Соединение" для обработки в ядро тоже неверно, т.к. не ядровое это дело :)

Я думаю, сделаем так:
1) В RADIUS будут библиотеки
kernel.jar (возможно разбита на несколько подбиблиотек)
dialup.jar
Соответственно эти библиотеки и синхронизуются с сервером. Ничего от нынешней ситуации не поменяется в общем, только что одновременно будет апдейт как модуля так и радуса происходить..

2) Если кому-то всё-таки нужны библиотеки сторонние, копирует, например первый раз npay.jar в lib радиуса и в дальнейшем она тоже синхронизируется.

Т.е. как и что делать - будет личное дело каждого.

Цитата:
Да ёлки палки! Этого можно добиться более архитектурно "красивым" способом, нежели подсовывать библиотеки npay и пр. радиусу.
1) Все асинхронные события радиус отправляет в ActiveMQ.
2) Все синхронные события исполняются в контексте радиуса
3) Если возникает нужда в библиотеке npay в синхронном событии радиуса, то у вас что-то архитектурно неправильно задумано.

У нас будут теперь "Синхронные локальные" и "Синхронные внешние события". Например, синхронное событие на активацию карты вполне можно послать в ядро.
А вот, RADIUS-аунтификацию вроде как не верно..

В конечном итоге всё служит целесообразности, в т.ч. и "красота" архитектуры.
"Красота" не конечный критерий. Конечные критерии: скорость, надёжность, гибкость, удобство сопровождения.
Да и то, это всё условно и субъективно. Поэтому оставим всё решать каждому.
Автор:  Cromeshnic [ 01 окт 2010, 13:07 ]
Заголовок сообщения:  Re: Единое API для всех приложений биллинга
Ок, я удовлетворён :)
Единственно, при каждом апдейте придётся рестартовать радиус.

2snark
К вам то нет претензий. В конечном счете всем нам нужно только, чтобы всё исправно работало. Меня испугал первый пост.
Автор:  ldmitry [ 12 окт 2010, 16:06 ]
Заголовок сообщения:  Re: Единое API для всех приложений биллинга
Вставлю пять копеек. ИМХО нужно проводить водораздел между ядром и модулями исходя из того, что на практике лучше.
Теоретически кажется, что надо, чтоб ядро владело абстракциями типа "сеанс", "тариф" и т.д., а модули снабжали его событиями и данными в этих высокоуровневых понятиях, а далее ядро тарифицировало. А модули бы занимались работой с конечным оборудованием, уже специфику обслуживали. Это один подход. Так сложно проектировать, кроме того, в результате дизайн может стать источником костылей в модулях, когда реализовывать специфику на основе заложенных в ядре абстракций станет невозможно.
Другой подход - реализовать все в модулях. Тоже плохо, т.к. повторяется код, дублируются сущности и т.д. Итог этого разделения порой ложится в UI так (пример этого дизайна LanBilling), что у пользователей системы появляется куча лишних бизнес-правил (типа "чтоб сделать так нужно в таком то месте сделать то-то и добавить ещё то-то и там сделать ещё миллион действий"). Вот как раз в LB это отчасти потому, что модули не получают перекрестного доступа к данным друг друга, не вызывают друг-дружкины классы и не оперируют сущностями друг друга - они полностью изолированы. Мы как заказчик наелись результатов этого дизайна :-(
Нужен компромисс, на который нас выводит практика и опыт проектирования, который накапливают разработчики системы которые, я надеюсь, внимательно слушают своих пользователей.
Я лично думаю, компромисс в том, что бы на уровень ядра выносить основные абстракции, которые как-то в общем соответствуют предназначению системы, но не лишать перекрестного доступа к данным и функциям модули, чтоб люди могли проще реализовать то, что им хочется. Бывает модуль предназначенный для списания за какую-то услугу должен менять свое поведение при наличии подключенной какой-то услуги другого модуля. Таких сценариев найдется миллион. Каждый из них аргумент в пользу взаимного доступа к данным и объектам всех модулей.
Автор:  Администратор [ 13 окт 2010, 13:47 ]
Заголовок сообщения:  Re: Единое API для всех приложений биллинга
Цитата:
Нужен компромисс, на который нас выводит практика и опыт проектирования, который накапливают разработчики системы которые, я надеюсь, внимательно слушают своих пользователей.

:)
Ядро должно уменьшится при объединении модулей DialUp + IPN в Inet и VoiceIp + Phone в объединённый Voice.
В ядре останутся, например, поддержка RADIUS протокола.
Поддержку NetFlow, sFlow и пр. в перспективе можно увести в Inet.
Тарифные узлы тоже увести голоса/трафика по модулям. Сейчас вот например, карты цен, карты зон, зоны и пр. вынуждены держать я ядре.
В 5.2 ядро будет ещё тяжелое..
Страница 1 из 1 Часовой пояс: UTC + 5 часов [ Летнее время ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/