BiTel

Собственно проблема возникла в этой ветке.
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) Возможность отправки событий радиуса на обработку, например, серверу. Т.к. классы везде будут единые.

так сделали же то что при меняние конфига радиуса рестарт ненужн...неполуится сделать так же и с этим???

А если всетаки посмотреть в сторону activmq ??

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

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


O_o


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


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

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

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


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


Ну модульности тут не убудет Просто эта модульность будет для всех приложений, не только сервера. Сейчас радиус фактически монолит.

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

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

"В контексте биллинга", ага. Контекст радиуса - это не контекст биллинга. Приведите пример синхронного события радиуса, требующего логики из контекста биллинга?

Я бы предпочёл, чтобы по свистку (который слышат все), каждый игрок начал делать свою работу в своём углу, вместо того, чтобы создавать броуновское движение.

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

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

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

1) Асинхронные события выгребаются сервером биллинга и исполняются в его контексте. AFAIK, Если дополнительно сконфигурить ActiveMQ, можно подписаться на эти события вообще любым приложением => profit!
2) 3) Радиус должен работать быстро и просто. Поэтому синхронные события по максимуму не должны использовать внешние вызовы, бизнес-логику и прочую сложную логику.

Да ладно вам. Может человеку аппаратная часть позволяет почасовой прогноз погоды на месяц рассчитывать по каждому пакету радиуса. Делал же тут кто-то реалтайм маршрутизацию VoIP посредством запросов в тарифные планы.
Припрет - спроксирует/скеширует с помощью того же Радиатора.

Ну вот запросы в тарифные планы - это стандартный функционал BGRadiusDialup.

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

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

По сути если использовать шину JMS, то можно взаимодействия компонентов БГ (радиус, ядро и.т.д) обеспечить за счет событий.
Обмениваться событиями (сообщениями) с помощью ActiveMQ.
Далее уже, как писал Cromeshnic

Т.е если Вам нужно будет выполнить какой-либо скрипт при определенном событии в радиусе (а это определенное сообщение в ActiveMQ) - то можно просто дополнительно своим листнером слушать topic и при определенных сообщениях выполнять свою логику.

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


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


у меня радиус работает и быстро и при этом до одурения просто (логика работы проста как мычание), может поэтому система которая "архитектурно неправильна задумана"(с) не заставляет меня задаваться вопросами статусов и прочими очень популярными тут, в обсуждениях, сентенциями? я изначально все архитектурно так неправильно задумал что все работает уже несколько лет без сбоев и косяки изредка вылазят только когда надо обновится, но я это быстро решаю и корабль плывет дальше

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

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

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

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


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

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

Ок, я удовлетворён
Единственно, при каждом апдейте придётся рестартовать радиус.

2snark
К вам то нет претензий. В конечном счете всем нам нужно только, чтобы всё исправно работало. Меня испугал первый пост.

Вставлю пять копеек. ИМХО нужно проводить водораздел между ядром и модулями исходя из того, что на практике лучше.
Теоретически кажется, что надо, чтоб ядро владело абстракциями типа "сеанс", "тариф" и т.д., а модули снабжали его событиями и данными в этих высокоуровневых понятиях, а далее ядро тарифицировало. А модули бы занимались работой с конечным оборудованием, уже специфику обслуживали. Это один подход. Так сложно проектировать, кроме того, в результате дизайн может стать источником костылей в модулях, когда реализовывать специфику на основе заложенных в ядре абстракций станет невозможно.
Другой подход - реализовать все в модулях. Тоже плохо, т.к. повторяется код, дублируются сущности и т.д. Итог этого разделения порой ложится в UI так (пример этого дизайна LanBilling), что у пользователей системы появляется куча лишних бизнес-правил (типа "чтоб сделать так нужно в таком то месте сделать то-то и добавить ещё то-то и там сделать ещё миллион действий"). Вот как раз в LB это отчасти потому, что модули не получают перекрестного доступа к данным друг друга, не вызывают друг-дружкины классы и не оперируют сущностями друг друга - они полностью изолированы. Мы как заказчик наелись результатов этого дизайна
Нужен компромисс, на который нас выводит практика и опыт проектирования, который накапливают разработчики системы которые, я надеюсь, внимательно слушают своих пользователей.
Я лично думаю, компромисс в том, что бы на уровень ядра выносить основные абстракции, которые как-то в общем соответствуют предназначению системы, но не лишать перекрестного доступа к данным и функциям модули, чтоб люди могли проще реализовать то, что им хочется. Бывает модуль предназначенный для списания за какую-то услугу должен менять свое поведение при наличии подключенной какой-то услуги другого модуля. Таких сценариев найдется миллион. Каждый из них аргумент в пользу взаимного доступа к данным и объектам всех модулей.

Ядро должно уменьшится при объединении модулей DialUp + IPN в Inet и VoiceIp + Phone в объединённый Voice.
В ядре останутся, например, поддержка RADIUS протокола.
Поддержку NetFlow, sFlow и пр. в перспективе можно увести в Inet.
Тарифные узлы тоже увести голоса/трафика по модулям. Сейчас вот например, карты цен, карты зон, зоны и пр. вынуждены держать я ядре.
В 5.2 ядро будет ещё тяжелое..