2017 年も DevWire をよろしくお願いします! - DevWire (2017/1/30)
| 2017 年 1 月号 | |||
|
||||||||||||||
|
||||||||||||||
| Hot Topics | ||
| 今年も見せます! マイクロソフトの流通向けソリューション | ||
| 寒さが厳しくなりましたが、いかがお過ごしでしょうか? 春が待ちきれませんが、春の到来を感じさせるイベントと言えばリテールテック Japan |
||
| Windows 10 Enterprise E3 ライセンスの Qualifying OS に Windows 10 IoT Enterprise が追加! | ||
| この特典変更に伴い、これまで VDA ライセンスの購入が必要だった Windows 10 IoT Enterprise OS をご利用のお客様も Windows 10 Enterprise E3 ライセンスの購入で各種特典をご利用いただくことができます。「え!? そもそも Windows 10 Enterprise E3 って何?」という声が聞こえてきそうですが、これまでは、ソフトウェア アシュアランスという呼び名でボリューム ライセンスとして企業のお客様にご購入いただいておりました。マイクロソフトの提供する製品、テクノロジー、サービス、使用権などをセットで特典として提供しており、常に最新バージョンを使えるなどのメリットがありました。Windows 10 Enterprise E3 は、7 月に開催したマイクロソフトのパートナー向けカンファレンスである WPC (Worldwide Partner Conference) で発表されており、Windows 10 Enterprise を 1 ユーザーあたり月額 7 ドルのサブスクリプションで購入することができ、その中にはソフトウェア アシュアランス時代と同様、VDA ライセンスを含むさまざまな管理ツールや機能が特典として含まれています。エンドユーザー企業様向けのライセンスにはなりますが、Windows 10 IoT Enterprise 搭載の組込み機器を購入してお使いの企業がこの E3 ライセンスをうまく活用していただくことで、お得になる場合がありますので、ぜひ、チェックしてみてください。 |
| 組込み製品に付加価値を! 新ビジネスをお手伝いします! | ||
| Azure IoT Gateway SDK を使ってみる | ||
| 2 年振りに DevWire に登場!! Windows Embedded MVP "株式会社デバイスドライバーズ 代表取締役社長 日高亜友さん" から Azure IoT Gateway SDK について執筆していただきました。「前編」「後編」、2 号にわたってお送りします。 | ||
| 昨年の 11 月 GitHub で Microsoft Azure IoT Gateway SDK のリリース版 |
| 以上で準備ができました。今回はここまでとさせていただきます。次回は実際にサンプル プログラムをビルドしてインストールする手順を示します。次回もお楽しみに! |
| DevWire のバックナンバーをご紹介 | ||
| これを読めば組み込み業界のすべてが網羅できる!DevWire バック ナンバー サイトはこちら | ||
| 【正規販売代理店情報】 | ||
| アドバンテック株式会社 統合 IoT ソリューション |
| 【セミナー・トレーニング情報】 | ||
| 多くのセミナー、トレーニングを開催しております。ぜひご活用ください。●アヴネット株式会社 トレーニング |
| Column | ||
| 今まで「IoT に適したプロトコルの要件を探る」と題して 5 回にわたって連載をして参りましたが、いよいよ今回が最終回となります。8 月号の「MQTT と AMQP の共通の特徴である MQ (Message Queue) についておさえておこう」に関して「MQTT は MQ (Message Queue) ではない」という指摘を受けました。ということで、今回はこの点について考えてみたいと思います。MQ (Message Queue) とはネット上のノード間以外にも同一ノード内のプロセス間やスレッド間の通信に使われるソフトウエア コンポーネントです。たいていの場合 FIFO (先入先出) タイプのバッファーに Queue (キュー) いわゆる行列 (数学でいう行列ではなく「行列のできる○○」の行列の意) が構成されます。送信側のメッセージはキューにいったん格納され、キューにあるメッセージは受信側が取り出すまで格納されます。そのため送受信間で同時にメッセージをやり取りする必要がなく、いわゆる非同期のメッセージ交換を実現しています。それでは本題の MQTT は MQ であるかという問題ですが、MQTT V3.1 プロトコル仕様には MQTT が MQ であることはどこにも書かれていません。また MQTT を MQ Telemetry Transport と表記しており、以前は MQ のところを Message Queue とは表記していたところを、最近は MQ としかあえて表記していません。なので仕様書では MQTT がメッセージ キューであることを暗に否定していると解する向きもあります。しかし仕様を細かく読んでみると、MQ の実装が適切ではないかと思われる箇所があります。そのひとつが Clean Session の扱いです。これはサブスクライバー (メッセージを受信する側) がブローカー (メッセージを仲介するサーバー) に接続するときに設定するフラグです。これを 1 に設定して接続に行くとブローカーは以前に保持していたサブスクライバーに関する情報をすべて破棄します。またサブスクライバーが接続を切断した時にブローカーはそのサブスクライバーの情報をすべて破棄します。一方このフラグを 0 に設定して接続にすると、ブローカーはサブスクライバーの都合で接続を切断した場合でもサブスクライバーの情報を保持しなければなりません。そしてこれは QoS という通信品質を保証するレベルにもよりますが、ブローカーは同じサブスクライバーが再接続するまで、接続が失われた間のメッセージを保持する必要があります。これらのことから MQTT を実装するうえでメッセージを保持するなんらかの機能が必須であることはお解り頂けたかと思います。確かにそれが MQ (Message Queue) である必要はないかとは思いますが、システムを実装するエンジニアにとって最初に頭に浮かぶのが MQ ではないでしょうか。今回は MQTT V3.1 のプロトコル仕様に記載されている Clean Session というサブスクライバーがブローカーに接続にする際に設定するフラグをもとに、MQTT が MQ であるかというテーマで考えてみました。MQTT に詳しくないとわかりづらい術語が多々出てきたと思います。たとえばブローカーとかサブスクライバーとか QoS とか、これらについては順次コラムの中でも扱っていきたいと思っています。その後でこのテーマを思い出したらもう一度読み直して頂ければ幸いです。このシリーズは今回を持って最終回となりますが、現在新しい企画も検討中です。また読者の皆様とは誌面でお目にかかれることを楽しみにしております。 |
| ほっとひと息 | ||
| 編集後記「お正月は・・・」DevWire 編集部 加藤 大輔 | ||
| 遅ればせながら、明けましておめでとうございます。今年もよろしくお願いします。12 月号で予告したとおり見事に寝正月だった加藤です。寝正月だったにもかかわらず体調を崩したおかげで体重が増えずにすみました。ここは思い切って幸先がよいことにします!ここ数年、「年末年始の独特な雰囲気」が無くなっている気がします。個人的には冬のゴールデンウイークみたいだなと思いました。あの独特の雰囲気を感じなくなったのは、年末年始だからこそする特別なことを、あまりしなくなったからかもしれませんね。 |