Comparación de la biblioteca SMPP de Java

(7)

Actualmente estoy implementando una solución SMPP sobre Java usando la biblioteca de Logica. Es muy fácil de usar. La siguiente información indica el resultado de las pruebas:

Aplicación: Aplicación Enterprise Java Beans implementada en Glassfish 3.1.2.2
Idioma: Java (usando JMS)
Biblioteca: Logica SMPP (versión 1.3)
Origen (ESME): localhost
Destino (SMSC): Simulador de Logica SMSC en el servidor de desarrollo (alojado en Amazon Web Services)
Tipo: Transciever Asíncrono
Promedio de tasa de envío (80%): 246 msg / seg.
Baja tasa de envío (15%): 50 msg / seg.
Alta tasa de envío (5%): 255 msg / seg.

Es muy eficiente siempre que te mantengas en el modo asíncrono. Si necesita mantener una correlación entre el mensaje y su respuesta, use el "número de secuencia" que se encuentra tanto en el mensaje como en la respuesta.

Estamos a punto de comenzar un proyecto que requiere el uso de SMPP como el principal canal de intercambio de integración. Ahora que los SMS no son necesariamente fundamentales para nuestro negocio, me gustaría usar una biblioteca SMPP para Java que sea la menos problemática. Aparte de utilizar el protocolo real, es improbable que necesitemos habilidades más sofisticadas o que alguna vez se modifiquen bajo el capó.

Para ello, he preseleccionado algunas de las posibles opciones que tenemos:

Open SMPP de Logica
El camello de apache
JSMPP
Cloudhopper de Twitter

¿Puede alguien que tenga más experiencia en sus usos lanzar algunas de sus experiencias a mi manera?

EDITAR: Solo para dar alcance a los casos de uso, enviaremos y recibiremos SMS, por lo que la biblioteca debería facilitarle la vida tanto con la acción del cliente como con la implementación de la escucha del servidor.

Cloudhopper es la mejor opción, Apache''s Camel también es bueno, pero es un proyecto muy grande que tiene muchas interfaces para pdf, fuerza de ventas ... que no necesita. Otro proyecto no está actualizado hasta la fecha. Cloudhopper mantiene por Telestax y agrega algunas características útiles y parece que le darán un gran apoyo en el futuro

Aquí está la pila para facilitar la configuración de Cloudhopper https://github.com/RestComm/smpp-extensions Aquí está bifurcado Cloudhopper por telestax (muy actualizado): https://github.com/RestComm/cloudhopper-smpp También JainSlee Adaptador de recursos para quien quién está trabajando en el campo de las telecomunicaciones https://github.com/RestComm/jain-slee.smpp

He usado jsmpp y cloudhopper-smpp para proyectos separados que involucraron el envío y recepción de SMS a través de smpp en circunstancias que involucraron:

Recibiendo un número medio-alto de MOs.
Envío de alto número de MTs (hasta 70 / segundo).

Tanto a las bibliotecas les fue bien, como a IMO jsmpp es más fácil de usar e iniciar la codificación de inmediato. Pero me encontré con algunos errores mientras utilizaba la última versión de github, que aún permanece sin corregir.

Después de haber utilizado cloudhopper, creo que vale la pena la curva de aprendizaje, que es un poco empinada en comparación con jsmpp (subjetiva).

He usado Logica SMPP para un proyecto de producción. Ya no se mantiene de forma activa y hay algunos errores inherentes que han tenido que producir soluciones alternativas o, de hecho, forzar el código base para solucionarlo. Habiendo dicho eso, he encontrado que la API es muy estable y eficaz (300msg / s).

He mirado brevemente a JSMPP y tiene una API mucho mejor que Logica, aunque parece que hay una gran cantidad de defectos que no se han solucionado a pesar de haber estado en la lista de problemas durante mucho tiempo.

Acabo de encontrarme con Cloudhopper SMPP, que parece estar codificado en un estilo más actualizado, pero nuevamente necesita más ejemplos. Tener que repasar el código base no es atractivo. Sin embargo, los ejemplos en gituhub están mejorando.

He usado tanto jsmpp como smppapi y encontré a este último mucho mejor porque jsmpp solo tenía un modo de bloqueo síncrono en ese momento (2010), no estoy seguro de que ese sea el caso.

La naturaleza de bloqueo de jsmpp se convierte en el origen de grandes problemas cuando el servidor SMPP al que me estaba conectando experimentaba algunos problemas de rendimiento y respondía más lento de lo habitual. De repente, encontré que todos mis hilos estaban esperando respuestas. La migración a smppapi solucionó los problemas obviamente.

Nuestro SMSC fue escrito en Logica SMPP (v 1.3), aún funciona muy bien con cargas empresariales. Solo ha habido algunos pequeños problemas con respecto a la biblioteca, principalmente con message_payload, honestamente no recuerdo otros problemas. Pero es fácil de reparar porque es un producto de código abierto.

Aunque personalmente confío en las fuentes de Logica, para clientes pequeños uso jsmpp. Estoy de acuerdo con @Farhan en que es un poco más fácil de usar y el desarrollo de un cliente sencillo lleva menos tiempo.

Solo una actualización de lo que finalmente decidí (y cómo revisaron las bibliotecas):

Lógica: parece prometedor, pero me preocupaba la falta de actualizaciones / actividad de la comunidad en general. La última construcción significativa fue hace un año atrás, así que no era realmente una inversión que quería hacer.
Apache Camel: Comenzamos a usar esto, pero su biblioteca tenía algunas limitaciones (necesitábamos insertar cabezas personalizadas en nuestros paquetes SMPP). Para ser justos, fueron bastante rápidos en responder a los problemas en sus foros, pero sus ciclos de construcción tardaron un poco demasiado en mis carreras, así que lo corregimos.
JSMPP: Este es el que terminamos usando. En general, fue bastante sencillo, pero parecía que esperaba que ya tuvieras una idea bastante buena de SMPP en general. Las cosas se están preparando, así que no puedo decirle cómo funciona bajo la carga de producción. Se actualizará cuando se ponga en marcha.
Cloudhopper: Para ser honesto, este era el que tenía más ganas de usar, pero más porque, como cualquier geek, quería saltar al juguete más nuevo y brillante disponible. Realmente no recibí respuestas adecuadas a ninguna de las preguntas que hicimos desde el principio, por lo que estaba aprensivo de abordar. No hay razón para adoptar una biblioteca que me obligue a leer sus códigos cuando haya otras opciones más documentadas disponibles.