エンタープライズ ソフトウェア システムと対話する必要がある組み込みデバイスがあります。
エンタープライズ システムは現在、コンポーネント間の通信にさまざまなメカニズムを使用しています。ODBC、RPC、TCP/IP 上の独自のプロトコルであり、.Net で実装された Web サービスに移行しています。
組み込みデバイスは *nix のフレーバーを実行するため、最適な対話メカニズムを検討しています。
通信の要件は次のとおりです。
SO-land で他に提案がある人はいますか?
編集：スティーブンの答えは、私に最も新しい指針を与えてくれました。ありがとうございます！
SSL over TCPを使用することはできませんか？
ある種の*nixをお持ちの場合（推測できますか？QNXまたは組み込みLinuxのどちらかですよね？）、イーサネット、USB、RS232を介して箱から出してすぐに動作するはずです。物事をシンプルにしてください。
32MBは、このタスクに十分なメモリです。ネットワークと暗号化（コード+データ）用に2〜4MBのメモリを割り当てます。
HTTPS (定義上、TCP/IP を使用) を使用する RESTful サービスを定義でき、任意の量のデータを転送できます。
SOAP に対する REST の利点は、REST の方が単純であることです。より単純な XML の代わりに JSON を使用できます。
SOAP プロトコルよりもオーバーヘッドが少なくなります。
RS232 を使用してアプリケーションを接続する場合は、PPP を使用してデバイスをインターネットに接続することを想定しています。ただし、転送することを提案しているデータの量はやや気になります。ほとんどの RS232 接続は 115200 ボーに制限されており、TCP/IP/PPP フレーミングに必要なオーバーヘッドを無視すると、1 秒あたり最大 11,000 バイトの転送速度になります。これは、意図した転送を行うのに少なくとも約 2800 秒または 46 分かかることを意味します。
これを SOAP のようなリモート プロシージャ コール プロトコルに結び付けたい理由は明確ではありません。あなたが言及していない他の要件はありますか？
ただし、一般に、この種のことは、通常の Web ベースのサービスを使用して非常に簡単に処理できます。C で書かれた非常に軽量な http プロセッサを入手できます。それらのいくつかの比較については、このウィキペディアの記事を参照してください。その後、REST インターフェイスは正常に機能します。USB を TCP 接続として扱うネットワーク インターフェイスもあります。
RS232 経由で実行できる必要がある場合は、別の場所を探すことをお勧めします。その場合、sftp のようなものがうまくいくかもしれません。または、暗号化された接続で実行できる単純なアプリケーション層プロトコルを記述します。