20

SMPP を主要な統合交換チャネルとして使用する必要があるプロジェクトを開始しようとしています。SMS は必ずしも私たちのビジネスの中核ではないので、Java 用の SMPP ライブラリを使用したいと考えています。実際のプロトコルに乗ることは別として、より手の込んだ機能が必要になったり、ボンネットの下で微調整したりする必要はほとんどありません.

そのために、私たちが持っている可能なオプションのいくつかを最終候補に挙げました。

  • ロジカのオープンSMPP
  • アパッチのラクダ
  • JSMPP
  • Twitterのクラウドホッパー

使用経験が豊富な人は、自分の経験の一部を私のやり方で投げることができますか?

編集: ユースケースに範囲を与えるために、SMS の送受信の両方を行うため、ライブラリがクライアント アクションとサーバー リスナーの実装の両方で楽になることを願っています。

4

8 に答える 8

14

私は、次のような状況で smpp を介して SMS を送受信する別のプロジェクトに、 jSMPPとcloudhopper-smppの両方を使用しました。

  • 受信中の MO 数。
  • 多数の MT を送信しています (最大 70/秒)。

どちらのライブラリもうまく機能し、IMO jSMPP の方が使いやすく、すぐにコーディングを開始できます。しかし、GitHub の最新バージョンを使用しているときに、まだ修正されていないいくつかのバグに遭遇しました。

cloudhopperを使用した後、jSMPP (主観的) に比べて少し急な学習曲線を使用するだけの価値があると思います。

于 2013-01-21T12:01:21.467 に答える
7

私が最終的に決定したもの（およびライブラリのレビュー方法）を更新しました：

  1. Logica：有望なようですが、コミュニティ全体の更新/アクティブ性の欠如について懸念していました。最後の意味のあるビルドはずっと前だったので、私がしたかった投資ではありませんでした。

  2. Apache Camel：これを使い始めましたが、ライブラリにいくつかの制限がありました（SMPPパケットにカスタムヘッドを挿入する必要がありました）。公平を期すために、彼らはフォーラムの問題にかなり迅速に対応しましたが、ビルドサイクルは私のスプリントには少し時間がかかりすぎたので、これをスクラッチしました。

  3. JSMPP：これは私たちが最終的に使用したものです。全体的にはかなり単純でしたが、SMPP全般についてすでにかなり良いアイデアを持っていることを期待しているように感じました。物事はステージング中であるため、本番環境でどのように機能するかはわかりません。公開時に更新されます。

  4. Cloudhopper：正直なところ、これは私が使いたがっていたものでしたが、他のオタクと同じように、入手可能な最も光沢のある最新のおもちゃに飛び乗りたかったのです。オフからの質問に対しては、十分な回答が得られなかったため、参加するのが不安でした。他のより文書化されたオプションが利用可能になったときに、コードを通り抜ける必要があるライブラリを採用する理由はありません。

于 2013-03-18T21:27:15.697 に答える
2

私たちの SMSC は Logica SMPP (v 1.3) で書かれていますが、エンタープライズ ローディングでも非常にうまく機能します。主に message_payload を使用するライブラリに関して、いくつかの小さな問題しかありませんでした。正直なところ、他の問題は覚えていません。しかし、オープンソースの製品なので、簡単に修復できます。

個人的には logica のソースを信頼していますが、小さなクライアントには jsmpp を使用しています。私は@Farhanに同意します。それはもう少しユーザーフレンドリーで、シンプルなクライアントの開発に時間がかかりません。

于 2014-07-08T07:03:15.187 に答える