IoT platform でプロジェクト・エンティティをモデル化する方法に関するヒント¶
プラットフォームでプロジェクトをモデル化する方法を設計する際には、いくつかの考慮事項があります。このドキュメントでは、一般的な間違いを避けるためのヒントをいくつか示します。厳密な規則ではなく、モデリングをガイドするためのヒントとして使用してください。
IoT platform はコンテキストに集中しています¶
IoTプラットフォームの中心的部分は、Context Brokerです : コンテキスト・エンティティに関する情報の保管とクエリを可能にするコンポーネントです。しかし、コンテキスト・エンティティとは何ですか？コンテキスト・エンティティは、システムの要素を表す論理抽象です。いくつかの例があります :
- スマートシティをモデリング : Streetlight, Garden, Bus, Street, RecycleBin などのエンティティを持つことができます
- インダストリーのモデリング : 作業者、機械、製品などの有益なエンティティを見つけることができます
- スマートパーキングを設計するときは、カー、ユーザ、フロアなどのエンティティがあります
これらのオブジェクトが、クラス,オブジェクト,テーブルまたはドキュメントに代わりにコンテキスト・エンティティであることは、どういう意味ですか？ その違いは、プラットフォームの周りにどのように処理されるかという点です。サブスクリプションによって、コンテキスト・エンティティの変更を観察することができます。永続性バックエンド(HDFS,CKAN,MySQL) および STH に保存された変更の履歴、CEP によるコンテキスト・エンティティの変更に基づいてグローバルコンテキストを変更するルールを定義できます。
与えられたすべての例は、いくつかの共通点を持っています :
-
それらのすべてが名詞をモデル化する : コンテキスト・エンティティは相互作用の対象です。それらは履歴を持っている、変更にサブスクリプションを持っている可能性があります。この動作は、プロセスと典型的には動詞またはアクションとしてモデル化されたものとうまく適合しません。
-
それらのエンティティはすべて、システムの寿命が長いと予想されます。エンティティは、一時的な情報(例えば、サポートチケット、メール、ログファイル)をモデル化することは想定されていません。これは、短命のエンティティをシステムでモデル化できないことを意味するものではありませんが、プロジェクトにそのような種類のエンティティがあると、プラットフォーム内でいくつかの操作上の問題が発生します。
プラットフォームはチケット・システムではありません¶
別のよくある間違いとして、以下のシナリオのように、短期間のチケットのためのプラットフォームの使用があります :
-
センサによって検出されたアラームを追跡するシステム、およびそれらが解決されたかどうか。モデリングされたエンティティは、センサとアラームです
-
シアターシートの予約システム、各チケットをコンテクスト・エンティティとしてモデリングして。モデリングされたエンティティは、シートとチケットです
どちらの場合も、コンテキスト・エンティティに関する上記の規則に準拠しないコンテキスト・エンティティが存在します : チケットとアラーム。どちらのエンティティも、システム内で何度も作成される短命の要素をモデル化し、古い情報でサービスを乱雑にします。
チケットのようなオブジェクトは、たとえ名詞であっても、コンテキスト要素をモデリングするのではなく、システム内のエンティティ間の相互作用をモデル化します。チケットは、(同じシアターに何回も行くかもしれない)ユーザと（ユーザが特定の遊びのために座る）座席との時間的関連性です。この種の情報をモデル化するより便利な方法は、次の例 (NGSIv1) のように、座席に直接コード化することです :
{
"type": "Seat",
"isPattern": "false",
"id": "Row12SeatB",
"attributes": [
{
"name": "status",
"type": "String",
"value": "occupied"
},
{
"name": "play",
"type": "String",
"value": "Richard III"
},
{
"name": "audience",
"type": "Person",
"value": {
"name": "Bob Smith"
}
}
]
}また、NGSIv2形式の同じエンティティでは :
{
"type": "Seat",
"id": "Row12SeatB",
"status": {
"type": "String",
"value": "occupied"
},
"play": {
"type": "String",
"value": "Richard III"
},
"audience": {
"type": "Person",
"value": {
"name": "Bob Smith"
}
}
}このモデリングでは、Context Broker は、シアターの実際の画像を格納します : その座席は売られており、座席は売られていない。各座席の履歴は、過去の演劇の情報を提供することもできる(STH と他の履歴永続性バックエンドによって)。パフォーマンスとモデリングに関する推奨事項に従ってください。
しかし、このアプローチにはいくつかの注意点があります :
-
将来の出来事をモデル化することはできません(少なくとも簡単にはできません)。このような状況では、同じ席の将来の購入を別の日にモデリングすることは難しいでしょう。
-
過去の出来事とやり取りすることは許されません(もう一度、簡単にはできません)。座席の情報の一部が、過去の座席に対して変更される(例えば、視聴者による評価、または支払い領収書情報)可能性がある場合、、それは不可能です。いくつかの新しい情報が過去のアラーム通知について到着した場合、同じことが何度も発生したアラームのために行われます。
この種のモデルがあなたの問題に合わない状況では、チケットシステムや特殊なバックエンドを使って、問題のその部分を外部的に管理することを検討することができます。IoT Platform は、外部システムのデータをプラットフォーム内のデータとリンクさせる複数の方法を提供しているため、サポートや購入などの特定のプロセスに特化したツールを使用しながら、プラットフォーム機能を利用できます。
属性はコレクションではありません¶
初心者がプラットフォームで問題をモデル化しているときの間違いは、コンテキスト・エンティティの構造を見るためです。すなわち、他のオブジェクトのコレクション、属性、名前と値を持つアイデンティティを持つオブジェクトです。(NGSIv1) :
{
"type": "SensorMachine",
"isPattern": "false",
"id": "machine1",
"attributes": [
{
"name": "attr1",
"type": "String",
"value": "val1"
},
{
"name": "attr2",
"type": "String",
"value": "val2"
},
{
"name": "attr3",
"type": "String",
"value": "val3"
}
]
}または、NGSIv2形式の同じエンティティでは :
{
"type": "SensorMachine",
"id": "machine1",
"attr1": {
"type": "String",
"value": "val1"
},
"attr2": {
"type": "String",
"value": "val2"
},
"attr3": {
"type": "String",
"value": "val3"
}
}次のようなもののリストを含むオブジェクトを持つモデルに適合すると考えます :
{
"type": "DepartmentWorkers",
"isPattern": "false",
"id": "RRHH",
"attributes": [
{
"name": "Bob",
"type": "User",
"value": {
"name": "Bob",
"surname": "Smith",
"ID": "3456"
}
},
{
"name": "Alice",
"type": "User",
"value": {
"name": "Alice",
"surname": "Johnson",
"ID": "8744"
}
}
]
}または、NGSIv2形式の同じエンティティでは :
{
"type": "DepartmentWorkers",
"id": "RRHH",
"Bob": {
"type": "User",
"value": {
"name": "Bob",
"surname": "Smith",
"ID": "3456"
}
},
"Alice": {
"type": "User",
"value": {
"name": "Alice",
"surname": "Johnson",
"ID": "8744"
}
}
}いくつかの理由から、この問題のモデルは間違っています :
-
まず、Context Broker のクエリおよびサブスクリプション機能は、各モデル・エンティティが独立したコンテキスト・エンティティとして実装されるという仮説に基づいています。他のエンティティ内の情報をグループ化すると、厄介なクエリやサブスクリプションのロジックになります。クエリやサブスクリプションを実行できなくなることさえあります。
-
それはまた、パフォーマンス要因のために問題でもあります。いくつかの操作のパフォーマンスは、関連するコンテキスト・エンティティの属性の数に依存します。ますます多くの属性を持つコンテキスト・エンティティを作成すると、プロジェクトのパフォーマンスが損なわれる可能性があります。
-
また、Context Brokerのエンティティのサイズには物理的な制限があるため、サイズに応じて永遠に成長するエンティティをモデル化することはできない可能性があります。
同じモデリング問題を見つけることができる別のシナリオは前述のシアターシナリオです。このシナリオでは、素晴らしいモデルが次のようなシアターのコンテキスト・エンティティを持つことができると考えていた可能性があります(NGSIv1) :
{
"type": "Theater",
"isPattern": "false",
"id": "LondonShakespeareTheater",
"attributes": [
{
"name": "1-A",
"type": "Seat",
"value": {
"status": "Occupied",
"name": "Bob Smith"
}
},
{
"name": "1-B",
"type": "Seat",
"value": {
"status": "Free"
}
},
{
"name": "1-C",
"type": "Seat",
"value": {
"status": "Occupied",
"name": "Alice Johnson"
}
},
[...]
]
}または、NGSIv2形式の同じエンティティでは :
{
"type": "Theater",
"id": "LondonShakespeareTheater",
"1-A": {
"type": "Seat",
"value": {
"status": "Occupied",
"name": "Bob Smith"
}
},
"1-B": {
"type": "Seat",
"value": {
"status": "Free"
}
},
"1-C": {
"type": "Seat",
"value": {
"status": "Occupied",
"name": "Alice Johnson"
}
},
[...]
}このシナリオには、上の部門ワーカーのシナリオと同じ問題があります。各座席を単独でコンテキスト・エンティティとしてモデル化し、(座席内の属性を介して)座席に関するすべての情報を保持するサブサービスとして、または座席とのリンクを持つ別々のコンテキスト・エンティティのいずれかとして、シアターをモデル化することが最善でしょう。