Intel Edisonで iotkit-commを使うその3:Service SpecificationsとService Queriesについて.

前回のエントリの続き.
前回の説明ではJSONのサンプルとしてしか触れていなかった,Service SpecificationsとService queriesについてのもう少し詳しい説明.

もっと詳しいことを学ぶその3. Service Specifications と queriesについて

Service Specifications と queriesは,分散アプリケーションの開発をシンプルにするiotki-commライブラリの使い方を理解するためのキーだ.iotkit-commで記述された分散アプリケーションは,基本的にサーバとクライアントで構成される.
開発者はService を以下のステップで開発する.

  1. service specification を記述する
  2. specification に基づいたServiceを生成するために,iotkit-commライブラリへリクエストを行う

また,開発者はClientを以下のステップで開発する.

  1. Service query の記述
  2. queryに記述されたAttributesにマッチするServiceの発見と接続をiotkit-commへリクエストする

Service Specifications と queriesはとてもよく似ています.コードについて言えば,Service Specificationsオブジェクトは,Service queryの子となっています.しかし,これらの2つには,根本的な違いが2つあります.

  1. queryはClientによってのみ利用されるのに対して, specificationsはClient,Serverの両者で利用される.Specificationsが初期化や,Serviceへの接続に利用されるが,queryはServiceの発見のみに利用される.
  2. queryはIPアドレスやPortを含むことができないが,対して,Service Specificationは含むことができる.なのでこれらの情報は事前に共有されていないと考えたほうが良い.

ここで,少し脱線するけど,ネットワーク上のServiceを発見することが,どういうことなのかについて詳しく説明をする.
Service発見の機能にともなって,nameやProtocolによる検索を行い,IPアドレスやポート番号を獲得する.Serviceはネットワークでの最初のAdvertiseによってのみ発見される.Service Specificationsのうちの1つがService queryにマッチした時,Serviceを発見した,と言う.Service SpecificationsのAdvertisingとService Queryとのマッチングを管理するプロトコルは,mDNS(Multicast DNS)と呼ばれる.mDNSのコンセプトに基づくために,Service Specifications, query,それらのマッチングはiotkit-commによって抽象化されていることを覚えておいてください.

続いて,Service SpecificationsとQueryの書き方について説明します.これらはJSONで記述されます.

Service Specifications

以下はService Specificationsの例です. 例に続いて各Attributeの説明を行います.

Server Specificationsの例

{
    "name": "/my/home/thermostat/temperature_sensor",
    "advertise": {"locally": true, "cloud": false},
    "type": {
        "name": "zmqpubsub",
        "protocol": "tcp"
    },
    "type_params": {"ssl": false},
    "address" : "127.0.0.1",
    "port": 8999,
    "properties": {"dataType": "float", "unit": "F", "sensorType": "ambient"}
}

各フィールドについての説明

  • name(例外を除いてオプション): 文字列.なるべくユーザフレンドリなものを.Service namesは他のアプリケーションでも表示される可能性がある.
    ※ nameは,もしネットワーク上でServiceがAdvertiseされる場合には設定しなければならない.

  • advertise(オプション): このオプションが設定されない場合,ServiceはLAN内でAdvertiseを行います. ※ 現在のiotkit-commはクラウドでのAdvertising Serviceをサポートしていません.そのため現在は,”cloud”フィールドは無視されてしまいます.

  • type(必須): メッセージの送信受信方法は typeフィールドによって設定されます.typeフィールドは通常,”name”と,”communication plugin”を含みます.iotkit-commでは,プラグインがどのようにメッセージが送信されるかを抽象化するので,開発者はメッセージの内容にフォーカスすることができる.

    • name(必須): このServiceが話すプロトコルの名前を示す.これはまた,利用する通信プラグインの名前にもなる.
    • protocol(必須): トランスポートプロトコルの種別を示す.”tcp”もしくは”udp”のみがサポートされている.
  • type_params(オプション): 通信プラグインがサポートできる設定パラメータ.iotkit-commはこのパラメータをそのまま通信プラグインに引き渡す.

  • port(必須): サーバが動作するポート番号.
  • properties(オプション): Serviceが持つユーザプロパティ.各プロパティは,”name”: valueのペアで記述されなければならない.この場合の例では,センサが周囲の温度を華氏で,FloatでPublishする,という設定を行っている.
  • address(オプション): サーバが動作するアドレス.記述しなければlocalhostが利用される.

このSpecificationはmodule:main.createServiceに渡すことができ,最終的には指定されたアドレスとポートで動作しているServiceのインスタンスを返します.

Service Query

以下にService queryの例を示し,続いて各Propertyの説明を行います.

Server Queriesの例

{
    "name": ".*temperature_sensor",
    "type": {
        "name": "zmqpubsub",
        "protocol": "tcp"
    }
}

このqueryは,Service Specificationセクションで示したSpecificationsと一致していることが大事です.さらに,このqueryはzmqpubsubプロトコルを利用して通信を行う,LAN内の全ての温度センサを発見しに行きます.以上を念頭において各Attributeについて見てみましょう.

各フィールドの説明

  • name(オプション): 正規表現を利用可能.
  • type(必須)
    • name(必須): Serviceが利用する高レイヤの通信プロトコル.これによりClientは,数あるServiceの中から通信可能なものを探すことができる.例えば,type.nameフィールドに zmqpubsub を指定した場合,zmqsubscriber はzmq publishers のみを探すことができる.
    • protocol(必須): トランスポートプロトコル.”tcp”もしくは”udp”のみ利用可能.

このqueryはmodule:main.createClientに渡すことができ,最終的にはServiceに接続されたClientインスタンスが返されます.