Я работаю над приложением в домене Mobile / VOIP. Для меня это действительно серая зона. Вот некоторые подробности о приложении:

• Это в основном похоже на мобильную услугу с автоматическим пополнением / предоплатой
• Будет иметь логику средней сложности по сравнению с предыдущими приложениями ERP, которые я написал.
• Разделы «Представления» в ответе будут представлять собой обычный текст, который будет отправлен пользователю как запрос SMS / USSD, и голосовой XML (VXML), который будет отправлен как ответ IVR пользователям.
• Логика маршрутизации очень проста, поскольку для каждого типа ответа важны только два-три URL-адреса.

Ограничения:

У нас есть основная система, построенная на Perl (это устаревшая система, обслуживающая множество других услуг, связанных с VOIP / Mobile), и система бухгалтерского учета для отслеживания прибылей и убытков, но она выросла очень сложный. Поэтому мы решили сделать это приложение отдельно и использовать только SMS / USSD и IVR. Однако для целей бухгалтерского учета каждый пользователь этого приложения должен быть зарегистрированным пользователем базовой системы; этого легко добиться с помощью вызова API.

Теперь для отправки ответа / ответа для IVR и USSD нам нужно развернуть приложение у поставщика, который предоставляет эти возможности. Но мы не хотим, чтобы всегда приходилось входить на их серверы для ежедневных отчетов и бухгалтерского учета, поскольку для каждого из наших клиентов у нас будут разные потоки для системы USSD / SMS / IVR.

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

• Одно приложение будет обрабатывать интерфейс ПОЛЬЗОВАТЕЛЯ с доменом USSD / SMS / IVR и будет развернуто на серверах поставщика, которые мы будем называть «клиентское ПО».
• Второе приложение будет обрабатывать всю основную бизнес-логику и системы отчетности и будет развернуто на наших серверах, где у нас будет полный доступ. Мы будем называть это «промежуточное ПО».

Основной поток приложения:

1. Пользователь набирает короткий код.
2. Вызов поступает на серверы наших поставщиков, где клиентское приложение обрабатывает запрос и регистрирует его как пользователя в своей локальной базе данных.
3. Клиентское ПО также будет обращаться к промежуточному программному обеспечению через API. Чтобы зарегистрировать этого пользователя там, а также для основной бизнес-логики, своевременное автоматическое пополнение баланса и т. Д.
4. Промежуточное программное обеспечение затем также вызовет API-интерфейс основной системы, чтобы зарегистрировать этого пользователя также для целей бухгалтерского учета.

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

Из трех фреймворков, Rails , Padrino или Sinatra , подходят ли какие-либо из них специально для этого проекта? Я был бы признателен за хорошее сравнение с подробным описанием соответствующих плюсов и минусов, если это возможно.