Основными источниками SMS-сообщений являются такие приложения, как системы массовых рассылок, процессинга платежей, а также системы абонентского обслуживания. В результате с SMS-центрами по протоколу SMPP (Short Message Peer-to-Peer protocol — протокол, описывающий взаимодействие конечного клиента с SMS-сервером) взаимодействует достаточно большое число корпоративных приложений.
SMS-центры сотовых операторов представляют собой высокопроизводительные индустриальные решения, обслуживающие десятки миллионов абонентов. Однако их пропускная способность четко определена, и задача их оптимальной загрузки для наилучшего удовлетворения потребностей корпоративных приложений оператора является весьма актуальной.
Кроме того, прямое взаимодействие корпоративных приложений с SMS-центрами реализовать не всегда легко. В частности, многие производители SMS-центров отходят от стандартов (например, используют различные версии протокола SMPP), и проблема интеграции в этом случае усложняется.
Наконец, лицензионные соглашения между поставщиками SMS-центров и сотовыми операторами зачастую заключаются исходя из количества подключаемых к центру приложений. В этом случае организация множественных интерфейсов становится накладной, а при использовании единого источника сообщений удается достигнуть существенной экономии.
Все эти факторы делают вполне обоснованным построение интеграционного решения, направленного на упорядочение информационных потоков между приложениями и SMS-центрами. Конечно же, к такому решению предъявляются высокие требования по стабильности работы и производительности.
Например, если пропускная способность системы недостаточна, то приложение, информирующее пользователя или выдающее ответ на какой-либо запрос, не сможет отослать сообщение в приемлемое время. Как минимум это ведет к нагрузке на контакт-центр оператора, куда будут обращаться пользователи, не получающие необходимых сервисов в автоматическом режиме. Более серьезным последствием, разумеется, является снижение удовлетворенности пользователей.
Интересно, что зачастую даже при реализации решений, требующих высочайшей производительности и надежности, вполне оправданным является использование открытых технологий.
«Организацию взаимодействия корпоративных приложений с SMS-центрами вряд ли можно отнести к бизнес-проблемам, скорее это проблема архитектурная», — полагает Сергей Гусев, руководитель службы развития систем массового обслуживания компании «Вымпелком». В компании существует несколько SMS-центров и набор приложений, которые с этими центрами должны взаимодействовать. Очевидно, что у этой задачи может быть два решения: либо реализовывать во всех системах одинаковый интеграционный функционал, либо создавать единое решение, к которому подключаются все корпоративные приложения.
Действительно, SMPP-логику можно реализовать в каждом приложении, однако очевидно, что такой подход избыточен: все решения придется оснащать сходным функционалом. Гораздо целесообразнее другой подход — реализация промежуточного слоя, взаимодействующего с приложениями по простым и понятным протоколам. Все корпоративные приложения централизованно отправляют сообщения через SMS-шлюз, который фильтрует и накладывает предпочтения абонентов на отправляемые сообщения, выстраивая их в очередь.
Цена и эффективность
Попытки построить подобную систему в «Вымпелкоме» предпринимались уже давно, однако все созданные решения были далеки от идеала. Первое из них являлось собственной разработкой и существовало с 90-х годов прошлого века. Позже была предпринята попытка внедрить промышленное решение, однако требуемой пропускной способности снова достичь не удалось. После нескольких безуспешных попыток доработать внедренную систему «Вымпелком» продолжил поиски удовлетворяющего потребностям решения. Проведенный тендер выиграла компания Instream, предлагавшая решение SMS Dispatcher, построенное на платформе J2EE с использованием СУБД Oracle и Oracle GlassFish Server — сервера приложений с открытым исходным кодом, входящего в состав семейства Oracle Fusion Middleware. Решение предоставляет корпоративным приложениям, используемым в компании, интерфейсы SMPP, SOAP, MQ и SQL и охватывает потребности большей части приложений, отправляющих SMS.
При выборе системы оценивались два ключевых фактора: ее стоимость и производительность. «Данное решение развитого функционала не предусматривает. Это шлюз, и ничего, кроме упрощенной бизнес-логики по управлению предпочтениями абонента, от подобных систем не требуется», — полагает Гусев. Зато критерий производительности был весьма важен. Для достижения высокой производительности Instream отказалась от ставшего традиционным в подобных решениях разделения хранилища входящих и исходящих очередей сообщений. Таким образом, разработчики минимизировали взаимодействие между компонентами. Кроме того, ядро решения, став «монолитным», наиболее полно стало использовать возможности Oracle, благодаря чему обработка и отправка сообщений производится «на лету», напрямую из хранилища сообщений.
Любопытно, что предложенное Instream решение оказалось не только самым дешевым, но и наиболее отвечающим требованиям по производительности. «Вероятно, как на цену, так и на стоимость владения повлияло то, что решение построено на базе открытых технологий Sun и Oracle», — полагает Гусев.
Использованная при разработке платформа GlassFish позволяет практически бесплатно применять технологии Sun для построения решений высокой производительности. Совокупная стоимость владения существенно сокращается за счет минимизации затрат на лицензии. Во-первых, это позволяет при необходимости вложить дополнительные средства в аппаратную платформу. Во-вторых, компания имеет возможность выстраивать ту топологию, которая даст возможность получить максимальный эффект в скорости и надежности решения, не обращая внимания на стоимость лицензий. Речь может идти о горизонтальном или вертикальном масштабировании, объединении или разведении потоков от разных источников, введении резервных каналов обработки. Наконец, особенностью SMS Dispatcher являются относительно скромные требования к аппаратному обеспечению. Это позволяет построить достаточно мощные решения, даже используя серверы начального уровня. Выстроенная в «Вымпелкоме» система функционирует на базе серверной платформы Sun под управлением операционной системы Solaris 10.
Разумеется, в ходе проекта возникали определенные сложности, но они были связаны со спецификой функционирующих в компании систем, так как все возможные потребности, возникающие при интеграции, заложить в промышленное решение невозможно.
Технологии и бизнес
«Подсчитать экономический эффект от использования такого рода инфраструктурных сервисов довольно тяжело, — признает Гусев. — Тем не менее, если говорить с точки зрения бизнеса, речь идет о минимизации издержек компании». Это обусловлено как стоимостью внедрения любого нового решения, так и его сроками. Когда в корпоративном ландшафте появляется новая система, задачей которой является организация рассылок, при отсутствии промежуточного слоя весь интеграционный функционал пришлось бы дублировать. Это влечет как дополнительные средства на разработку, так и дополнительные риски. В конечном счете сроки вывода на рынок продукта, обслуживаемого данной системой, увеличатся.
Кроме того, при наличии единого интеграционного решения сокращается общая стоимость поддержки систем, участвующих в процессах. В частности, вместо множества администраторов, знающих протоколы SMPP и специализирующихся на отдельных системах, достаточно одного специалиста.
«Главным успехом проекта стало то, что в компании наконец появилось решение, полностью подходящее по производительности, — то, чего не было раньше», — подчеркивает Гусев. Достигнутой производительности, составляющей более 3 тыс. обрабатываемых сообщений в секунду, на данный момент вполне достаточно. Более того, система имеет определенный резерв, позволяющий наращивать количество подключенных к ней приложений.