研鑽、交流、そして共育。全国に拡がるIBMユーザーのネットワーク line IBMユーザー研究会
fream01 ようこそ ゲスト さま separate fream2
 
  logomark IBMユーザー研究会TOP

midashiID登録がまだの方はこちらからblankup

ID登録のススメ
IBMユーザー研究会
入会申し込み
お問い合わせ
 
   
 
 
Security
Analytics
Commerce
Cloud
Social
Systems
Watson
Topics
 <業種別>
金 融
保 険
製 造
流 通
公共・通信
 
 <IBMユーザー研究会主催>
Webセミナー blankup
 <IBM主催>
IBM Webセミナー blankup
OnDemandセミナー blankup
IBM YouTubeチャネルblankup
日本IBMホームページ
Easy Web Browsingヘルプ 拡大読み上げ
当サイトのURLは予告なく変更・削除されることがございますことを予めご了承ください。
7
 
Social
IoT時代に備えるIBM MessageSight
2014年11月01日掲載
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
メインフレーム・ミドルウェア 浅見 俊夫
 世の中では、スマートフォンや各種デバイスで様々な情報を入手したり発信したりするようになり、また、IoT(Internet of Things)やM2M(Machine-to-Machine)といったエリアも注目されています。当記事では、ここでの利用に最適化されたIBM MessageSightをご紹介します。話は、世の中がどういう方向に向かっているのか、その流れのために考え出されたMQTTというプロトコル、そして、そのプロトコルを実装したIBM MessageSightという順に進めます。
 
1. 世の中はIoTの時代へ
 ご存知のように、Internet of Thingsとは、“ものがインターネットにつながる“ということです。現在の世の中は、各人がスマートフォンやタブレットなどで、常時インターネットにつながり、情報を発信したり情報を入手したりと、机の上のPCがインターネットにつながっていた時代から比べて、ますますインターネット上を流れる情報は、大規模に、タイムリーになっています。この普及で、通信デバイスは小型化され、より消費電力も小さくなり、コストも小さくなってきています。こうなってくると、この通信デバイスを色々なものに搭載して、もっと便利にしようというのは必然の流れです。1人に1つとか2つとか、人の数のオーダーだったデバイスが、世の中の物の数、あるいは、パーツの数と、莫大に大きくなります。(図1)
image
 ある通信デバイスは、組み込まれたものの状態を発信し、ある通信デバイスは組み込まれたものを遠隔地から操作できるようにするかもしれません。いえ、もう既に身近なところから始まっているのです。世界では、家庭の電気メーターを検針員が確認しなくてもその値は電力会社に通知されていたり、スポーツ競技の得点や株価などの情報はブラウザのボタンをクリックしなくても、定期的にポーリングしなくても、得点がはいったり、取引が行われたら即時に通知されるのです。これからも、新しい、もしかしたら考えもつかなかった用途に、次々と利用されていくと考えられます。広域にわたるような場合、ものすごい数がある場合、人が行くのは危険な場所、常時情報の必要な場合、まだまだあるかもしれません。
既存のITシステムで、これらに接続する、あるいは、接続されることは可能でしょうか。可能です。でも、もっと最適化したものが考え出されたのです。それが、この記事でご紹介するIBM MessageSight(以下、単にMessageSight)なのです。
MessageSightの中核をなすメッセージングは、MQTTというプロトコルです。これは、IoTのために考え出された軽量なプロトコルであり、既にWebSphere MQの一部として実装され、お客様にもご提供されています。そして、これからのIoT時代に備え、ハードウェアから最適化したMQTTの実装が、MessageSightなのです。MessageSightを理解するため、まず、MQTTとはどういうものか見ていきましょう。
 
2. MQTTによる情報連携
2.1 MQTTの特徴
MQTTには、様々な特徴があります。この節では、HTTPや通常のメッセージングなどと比較しながら、その特徴を見ていきます。

(1) Pub/Subメッセージング
MQTTでの情報連携は、Pub/Subメッセージングで行われます。Pub/Subメッセージングでは、情報送信者はパブリッシャー、情報受信者はサブスクライバーと呼ばれます。パブリッシャーとサブスクライバーは、トピックと呼ばれる関心事の名前を共有し、そのトピックにメッセージとして情報を送り、そのトピックからメッセージを受け取ります。具体的な動きを、図2に示します。
image
(1)
サブスクライバーがメッセージを受け取りたいトピックに対して、仲介するPub/Subブローカー宛にサブスクライブ(購読)します。
(2)
パブリッシャーがそのトピックにメッセージをパブリッシュ(送信)します。
(3)
Pub/Subブローカーは、そのトピックをサブスクライブしているサブスクライバーにそのメッセージを配信します。

複数のサブスクライバーが、そのトピックにサブスクライブしている場合は、それぞれのサブスクライバーにそのメッセージを送信します。このあたりは、基本的に1つのメッセージは1つの宛先のみに送る一般に言うメッセージングとは違うところで、Pub/Subメッセージング、あるいは、MQTTを有効利用する鍵になる部分です。
情報を受け取るサブスクライバーは、最初にトピックにサブスクライブすると、その後はただ待っているだけで、そのトピックに情報の更新があるたびに、メッセージを受け取ることができます。HTTPで、定期的に、あるいは必要なときにポーリングして情報の更新があったら入手するのと比べて、Pub/Subメッセージングが有効に利用できるしくみです。

(2) HTTPと比べて圧倒的に軽量なプロトコル
さて、もう1つの特徴は、プロトコルのヘッダ部分を極力小さくすることで、通信にかかる時間、電力をおさえていることです。これは、組み込み型の小さなデバイスをも対象にしていること、必ずしも安定的な電源がない所でも、バッテリで長期間稼動できるようにするためです。HTTPの通信に比べると、数分の1の電力で済むようになっています。

(3 )非同期、疎結合、双方向通信
メッセージの送信元であるパブリッシャーと、送信先であるサブスクライバーの間に、MQTTブローカーが介在するため、パブリッシャーはサブスクライバーの状態を意識することなく、メッセージを送信することができます。(非同期)
また、パブリッシャーは送信するメッセージを誰が受け取るかを意識することなく送信します。ここまでは通常のメッセージングと同様です。さらに、Pub/Subメッセージングでは、パブリッシャーが送信するメッセージがいくつの受信者に届くかも意識する必要がありません。(疎結合) これは、その情報を必要とする受信者・受信アプリケーションを送信側に手を加えることなく追加できることを意味しています。もちろん、アクセス制御は、MQTTブローカーの実装において、サブスクライバーとブローカーの間で行われることが期待されています。
そして、MQTTブローカーと通信するクライアントは、パブリッシャーにもサブスクライバーにもなりえます。

◆◆ コラム ◆◆
少し横道にそれますが、MQTTには、MQTT-SNという特化型のプロトコルも定義されています。SNとは、センサーという意味です。当初は、MQTT-Sと呼ばれていましたが、何の”S”だかわからないということで、”SN”に変わっています。MQTTでは、メッセージのやりとりに、どのトピックについてのメッセージなのか、トピック・ストリングもやり取りされますが、階層化して定義するトピック・ストリングは長くなりがちです。“軽量”という観点で言えば、この文字列をメッセージに含めるのはもったいないということで、MQTT-SNではサブスクライブの時1度しか送らないように番号でおきかえる仕組みになっています。その他にも更なる軽量化が計られています。このMQTT-SNからMQTTへ変換するブローカーも用意されています。

(双方向通信) 自分が発信するときはパブリッシャーに、その他のときはサブスクライバーにという感じです。グループチャットを想像してもらえばわかりやすいかと思います。昔からあるボタンを押して話すトランシーバーも同じですね。(アメリカでは、大出力が可能だからでしょうか、今でも結構使われていますね。)

(4) オープン仕様
このMQTTは、現在、OASIS(参考文献参照)にて標準化が行われています。具体的には、V3.1.1のPublic Viewが行われています。また、アプリケーションを作成するためのライブラリ等は、EclipseのPachoプロジェクト(参考文献参照)から提供されています。その他、様々な情報をMQTT.ORG(参考文献参照)から入手できます。
image
2.2 MQTTの機能
(1)QoS(Quality of Service)
MQTTでは、メッセージのデリバリーをどのレベルの信頼性で行うかを指定できます。このレベルをQoSとして、3つのレベルで指定します。

QoS0 : (図3左)
メッセージは1回のみ送信されます。受信側は受信応答を返さないので、送信側は届いたかどうかの確認はしません。受信側から見ると、最大1回受け取ることになります。

QoS1 : (図3中)
メッセージは最低1回送信されます。送信側は受信側からの受信応答を受け取ります。この受信応答がない場合、送信側は再送します。メッセージ自体は受信側に届いていても、受信応答が何らかの原因でメッセージ送信側に届かない場合、メッセージ送信側は、再送することになります。この結果、受信側から見ると、最低1回受け取ることになります。これは重複受信がありうることを意味します。MQTTのヘッダには、再送時に立てるフラグ(DUP)とメッセージを識別するID(MessageId)がありますので、受信側はこれらの情報をもとに重複受信か判断することになります。

QoS2 : (図3右)
メッセージは正確に1回受信側に送られます。つまり、必ず受信側に届く上、2回届くこともありません。これを実現するために、送信側、受信側間を2往復の通信が発生するため、レイテンシが悪くなるデメリットがありますので、必要に応じて選択します。
image
(2)デュラブル・サブスクリプション(Durable Subscription)
コネクション切断の間にパブリッシュされたメッセージをMQTTブローカーが保持し、再接続時にサブスクライバーが受信できる機能で、不安定なネットワークを想定したものです。図4右が通常の場合、つまり、デュラブル・サブスクリプションなしの場合です。コネクションが切断し、再度接続したとき、前のサブスクリプションはブローカーに残っていないので、再度サブスクライブを実行し、それ以降にパブリッシュされたメッセージを受け取ることになります。つまり、この切断していた期間にパブリッシュされたメッセージは受け取れません。一方、図4左は、このデュラブル・サブスクリプションの場合です。コネクションが切断し、再度接続したとき、前のサブスクリプションがブローカーに残っているので、再度サブスクライブを実行する必要がなく、かつ、コネクションが切断している間にパブリッシュされたメッセージもブローカーが保持しているので、再接続と同時に直ちに受け取ることができます。コネクション切断の間のメッセージをどうするかという要件に従って、どちらのオプションを選ぶかを決定します。
デュラブル・サブスクリプションは、具体的には、サブスクライバーがブローカーに接続(connect)する際、および、再接続する際、“clean session”を指定しないことで設定できます。また、ブローカーは接続をClientIdに紐付けて保持しているので、同じClientIdで再接続する必要があります。(ClientIdについては、3.2 (3)ユーザー/グループ定義 を参照)
image
(3)リテイン・パブリケーション(Retained Publication)
特定のトピックに対して最後にパブリッシュされたメッセージをMQTTブローカーが保持し、新たにサブスクライブしたクライアントに渡せる機能です。通常は、サブスクライブした後にパブリッシュされたメッセージを受け取るわけですが、例えば、株価情報など、取引が発生しないと新たなメッセージがパブリッシュされないとなると、次の取引発生まで現在(直前)の株価がわからないという状況になります。この状況を回避するために、直前の株価をそのトピックに保持しておき、サブスクライブされると、ひとまず、その保持していたメッセージをサブスクライバーに届けるのが、この機能です。
この機能を使うには、パブリッシャーがメッセージを送信する際に、そのメッセージを“リテイン”にする指定をします。つまり、メッセージ単位に指定できることになります。
図5右は、通常のリテイン・パブリケーションでない場合の動きを示しています。サブスクライバーがサブスクライブすると、その後にパブリッシュされたメッセージを受け取ることになります。一方、図5左は、リテイン・パブリケーションの動きで、サブスクライバーがサブスクライブすると、その時、ブローカーに保持さているメッセージを直ちに受け取ることになります。
image
(4)遺言メッセージ(Last Will & Testament)
予期せずクライアントが切断された場合に、指定したトピックへMQTTブローカーが自動的にメッセージ送信する機能です。切断されたクライアントは、自らは切断されたことを通知するメッセージを送ることができないので、あらかじめブローカーにどのトピックにどういうメッセージを送るかを登録しておきます。ブローカーは、そのクライアントが切断されたことを検知すると、代わりに指定されたトピックにそのメッセージをパブリッシュします。図6は、この流れを図示したものです。ブローカー、クライアント間は、KeepAliveによって接続が確認されます。
image
2.3 MQTTアプリケーション
MQTTはオープン仕様ということもあり、様々な言語環境でアプリケーションを作成できます。ここでは、言語によらず、MQTTの登場人物であるパブリッシャーとサブスクライバーについて、その特徴をご説明します。とは言うものの、百聞は一見にしかず、ですので、Javaのサンプルコードも掲載します。詳細は割愛しますが、見ればわかるような簡単なコードで実装できます。

(5) パブリッシャー
パブリッシャーは、特定のトピックを指定して、メッセージを送るだけです。誰が受け取るのかは感知しません。考慮すべき点は、「MQTTの機能」でご説明した、QoSをいくつにするのか、リテイン・パブリケーションにするのかという点です。以下のサンプルコード1は、トピック “くだもの/みかん” に、メッセージ “10時から特売” をQoS1でリテイン・パブリケーションするJavaのサンプルコードです。

サンプルコード1 ---------------------------------------------------------------------
package com.ibm.mq.id;
import org.eclipse.paho.client.mqttv3.*; public class PubAsync {
public static void main(String[] args) {
try {
MqttClient client = new MqttClient(“tcp://192.168.11.11:16102”, “clientId001”);
MqttTopic topic = client.getTopic(“くだもの/みかん”);
MqttMessage message = new MqttMessage(“10時から特売”.getBytes());
message.setQos(1);
message.setRetained(true);
CallBack callback = new CallBack(“clientId001”);
client.setCallback(callback);
MqttConnectOptions option = new MqttConnectOptions();
option.setKeepAliveInterval(60);
option.setConnectionTimeout(10000);
option.setUserName(“username”);
option.setPassword(“password”.toCharArray());
client.connect(option);
MqttDeliveryToken token = topic.publish(message);
if (client.isConnected()) client.disconnect(10000);
} catch (Exception e) {
e.printStackTrace();
}
}
}
-------------------------------------------------------------------------------------
QoS1なので、Ack(受信応答)が帰ってきて送信が完了しますが、これを非同期に待っています。上のコードの最後のあたりでは、disconnectを発行していますが、送信が完了するまでこのdisconnectは完了しません。以下に示すサンプルコード2が非同期に呼ばれるコールバック用のクラスです。送信完了時には、deliveryCompleteが呼び出されます。この例では何もしないで終了しています。

サンプルコード2 ---------------------------------------------------------------------
package com.ibm.mq.id;
import org.eclipse.paho.client.mqttv3.MqttClient;
public class CallBack implements MqttCallback {
private String instanceData = “”;
public CallBack(String instance) {
instanceData = instance;
}
public void messageArrived(MqttTopic topic, MqttMessage message) {
// メッセージ受信時の処理。メッセージを受信してそのハンドリング
}
public void connectionLost(Throwable cause) {
// コネクションが切れたときの処理(再接続など)
}
public void deliveryComplete(MqttDeliveryToken token) {
// メッセージのパブリッシュが完了した時の処理
}
}
----------------------------------------------------------------------------------
(6)サブスクライバー
サブスクライバーは、どのトピックをサブスクライブするかを指定して、メッセージが送られてくるのを待ちます。サブスクライバーもQoSをいくつにするのか指定できます。また、接続時に、デュラブル・サブスクリプションにするのかも指定できます。
トピックの指定の仕方でパブリッシャーと少し違うのは、必ずしもスペシフィックにトピックを指定する必要がないことです。ここまで、“トピック”という言葉で済ませてきましたが、トピックと一言で言っても、実はちょっと複雑です。というのは、正確に言うと、トピックは、トピック・ストリングという階層構造をもった文字列になります。例えば、「くだもの/りんご」のように、項目が“/”で連結されていて、親子関係を指定できるのです。実は、“くだもの”の下に、“みかん”もあるかもしれません。そのときは、「くだもの/みかん」というようになります。
さて話は戻って、サブスクライバーがどのトピックをサブスクライブするかを決めます。「くだもの/りんご」をサブスクライブできるようにしましょう。その場合は、トピック・ストリングとして「くだもの/りんご」を指定するだけです。次に、“くだもの”の下全部の情報がほしいとします。「くだもの/りんご」にサブスクライブし、「くだもの/みかん」にサブスクライブしと、・・・・。大変ですね。そこで、ワイルドカードの出番です。「くだもの/#」をトピック・ストリングに指定すれば完了です。
ワイルドカードには、複数階層を意味する“#”と、1階層のみを意味する“+”がありますので、要件にしたがって使い分けます。
以下のサンプルコード3は、トピック 「くだもの/#」に、QoS1でデュラブル・サブスクリプションしているJavaコードです。一旦サブスクライブすると、非同期でメッセージを待ちます。その間、他の作業を行うことができますが、このサンプルでは、sleepしているところがそこに該当します。メッセージが来たとき呼ばれるコードは、パブリッシャーのところで登場したコールバック用のクラス(サンプルコード2)です。パブリッシュされたメッセージを受け取るときは、messageArived が呼ばれます。

サンプルコード3 ----------------------------------------------------------------------
package com.ibm.mq.id;
import org.eclipse.paho.client.mqttv3.MqttClient;

public class SubAsync {
public static void main(String[] args) {
try {
MqttClient client = new MqttClient(“tcp://192.168.11.11:16102”, "clientId001");
CallBack callback = new CallBack(“clientId001”);
client.setCallback(callback);
MqttConnectOptions option = new MqttConnectOptions();
option.setCleanSession(false);
option.setKeepAliveInterval(60);
option.setConnectionTimeout(10000);
option.setUserName(“username”);
option.setPassword(“password”.toCharArray());
client.connect(option);
client.subscribe(“くだもの/#”, 1);
Thread.sleep(30000);
client.disconnect();
} catch (Exception e) {
e.printStackTrace();
}
}
}
-----------------------------------------------------------------------------------
 
3. IBM MessageSightによるシステム構築
 前の章でご説明したMQTTは、IBM製品としては、WebSphere MQ、および、アプライアンス製品であるIBM MessageSightで利用できます。MQTTの仕様は、プロトコルとしての仕様であり、これをどう実装するかは個々の製品等に依存します。ここでは、2013年に登場したIBM MessageSightについてご紹介します。
image
3.1 IBM MessageSightの特長
実際にMQTTを使う上で重要なMessageSightの特長をご紹介します。何といっても、IoTでは、ものすごい数の接続が必要になるところが一番の特徴ですから、それに対応する必要がありますね。

(1) 大量のメッセージングが可能
1台のMessageSightで、100万台の同時接続を実現することができます。この100万台のMessageSightへの接続を60秒以内に完了できます。また、毎秒1000万件以上のQoS0のメッセージを処理します。高容量、高パフォーマンスのため、MessageSightを利用することで、サーバーの台数を数分の1に抑えることができます。これは、MQTTに特化した専用ハードウェア(アプライアンス)であることが大きな要因です。

(2) 高セキュリティと高信頼性
専用のハードウェア、専用のOSであること、そして、MessageSight上で動くファームウェアは、暗号化され、IBMの署名が施されていることから、DMZで稼動するにも問題ない高いセキュリティが保たれています。また、高可用性確保のため、ハイスピードのフェイルオーバーが可能なHA構成をとれるようになっており、40Gbpsのネットワークを使ってリアルタイムでスタンバイ機へのクローニングが行われます。

(3) 高機能、容易性
MQTTブローカーとしては、接続ユーザーの認証、各トピックへの認可、通信経路のセキュリティとしてSSL通信など、Webユーザーインターフェースやコマンドを使って、容易に設定できるようになっています。
通常のMQTTの他、WebSocket上のMQTTや、JMS、WebSphere MQと、外部との接続性も確保しています。JMS利用時には、Pub/Subプロトコルだけでなく、キュー・メッセージング・プロトコルもサポートしています。
3.2 IBM MessageSightの構成
MQTTは、パブリッシャーが特定のトピックに対してメッセージをパブリッシュし、サブスクライバーがそのトピックをサブスクライブすることで、メッセージの伝達が行われることは、MQTTの章でご説明したとおりです。このとき登場するトピックは、オブジェクトとして用意する必要はありません。WebSphere MQのようなメッセージングでは、基本的に、メッセージを授受するキューは事前定義しておきます。しかし、トピックは事前定義しませんので、設計において以下の2つの点を考慮する必要があります。
(1) パブリッシャーとサブスクライバーがメッセージの授受ができるよう仕様として定義する必要がある
(2) セキュリティの観点から、誰がどのトピックをパブリッシュできて、誰がどのトピックをサブスクライブできるかを指定する必要がある
この(1)については、キューの場合にも当てはまることですが、トピックでは特に必要です。キューの場合はキュー定義を見ることで確認できますが、トピックの場合はパブリッシュするまで、サブスクライバー側は確認しにくいからです。
続く(2)については、MQTTのプロトコルとしての仕様の外側のことで、各MQTTのインプリメンテーションで実装することになる内容です。この節では、「認可設定」といえるこの仕組みについてお話します。

(1) 設定オブジェクト
設定する内容は、表1のように4つのオブジェクトになります。各オブジェクトの関係は、図7のようになります。MessageHubは、単なるオブジェクトの入れ物なので、実質3つのオブジェクトを定義することになります。(図8) EndPointでは、この表のポリシーの他、通信経路のセキュリティのポリシーもオプションで指定することができます。SSL通信を行う場合は、この指定が必要になります。

表 1 設定オブジェクトの種類と設定方法
オブジェクト
設定方法
MessageHub ・定義体の入れ物。アプリケーション単位に作成がお勧め
・EndPointはそのMessageHub内のどのPolicyも利用可
(Endpointは他のMessageHubのPolicyは参照不可)
・MessageHubをまたがってトピックはアクセスされる
EndPoint ・NIC(IPアドレス)およびポート毎の定義体
(どのNICのどのポートからのリクエストを受け付けるかを指定)
・1つのMessageHub内に複数定義可能
MessagingPolicy ・誰が、どの宛先(トピック/キュー)に、どうアクセスできるかを指定
・宛先は、トピック/キューの別、その名称(ワイルドカード可)を指定
ConnectionPolicy ・誰が接続できるかを指定
image
image
(2)MessagingPolicyでのトピック指定
前項の指定の中で、このMessagingPolicyで指定するトピックの部分については特徴的ですので、説明します。ここでは、どのトピックに対して、誰がどうアクセスできるかを指定します。正確に言うと、誰がどのようなトピック・ストリングを指定できるかということになります。
実際には、1つ1つのトピック・ストリングを指定するのは現実的ではない場合もあるので、ここでもワイルドカードを利用することができます。「*」と指定すれば、任意のトピックス・ストリングが指定した条件でアクセス可能になります。「くだもの/*」とすることで、“くだもの”の下のトピックにアクセス設定できます。その他、{$UserId}などの変数も用意されています。「くだもの/{$UserId}」と指定すると、この1つの定義で、AAAさんは「くだもの/AAA」に、BBBさんは「くだもの/BBB」にアクセス可能になります。

(3)ユーザー/グループ定義
お決まりのユーザーとグループの定義です。このユーザーを先のMessagingPolicyやConnectionPolicyで誰がアクセスできるかを指定できます。定義の仕方は、MessageSightのローカルに定義する方法と、LDAPを利用する方法の2通りがあります。ユーザーとグループについては、通常の考え方と変わりありません。ユーザー定義の際はパスワードも合わせて登録します。
このユーザーは、“UserId“として識別されますが、MQTTでは、もう1つ、”ClientId”というものがあります。ここまでの文章の中で何度か登場していますが、ClientIdは、接続のエイリアスとして使用されるIDです。従って、MQTTのブローカー内、つまりMessageSight内で、ClientIdは一意である必要があります。デュラブル・サブッスクリプションで再接続する際は、同じClientIdである必要がありましたよね。一方、UserIdはユーザーが誰かを識別し認証するIDであり、複数の接続で同じUserIdを使用することもできます。

3.3 IBM MessageSightとの接続
ここまで、デバイスなどのクライアントとMessageSightがMQTTプロトコルで接続されるお話をしてきましたが、クライアントからMessageSightを通じて送られてきた情報は、既存のバックエンドシステムに連携する必要があるかもしれません。逆に、クライアントに送る情報は、既存のバックエンドシステムから入手するかもしれません。ここでは詳細は触れませんが、こういったバックエンドシステムとの連携は、MQTTはもちろん、JMSや、WebShereMQなどを利用することができます。
 
4. おわりに
 この記事を読んでいただいた読者の方が、IoTやMQTT、MessageSightの基礎知識を得られ、また、この記事がお客様の問題解決のヒントになれば幸いです。キーとなるポイントを書いたつもりですが、短い文章の中では、尽くしきれない部分も多々あるのは否めません。もう少し詳しく知りたい、これは使えるかもと、関心を抱いていただいたら、文末の参考文献から、必要な情報をご参照ください。以前に実施したMQTTやMessageSightのセミナーでは、これらのご紹介や、設計にあたっての方法論などもご紹介しています。
 


 
 
 
サイトマップ関連リンクプライバシーポリシーblankupご利用にあたってblankup
ページのトップへ