JP2018512645A - メッセージバスサービスディレクトリ - Google Patents

Abstract

本明細書では、「オープンメッセージバス」（ＯＭＢ）と称されるメッセージングシステムアーキテクチャが提示される。ＯＭＢは、サービス間のコネクティビティおよび通信を促進するメッセージングシステムインフラストラクチャである。ＯＭＢバックボーンは、ＯＭＢに接続する全てのサービスによって活用されることができるインフラストラクチャサービスを提供し得る。一実施形態において、方法は、メッセージブローカに関連付けられている利用可能なサービスについての情報を第１のサービスから要求することと、利用可能なサービスの記述を含む応答を受信することと、応答からの利用可能なサービスのうちの第２のサービスを精査することと、応答内の第２のサービスの記述に基づいて、メッセージブローカと接続することとを含む。

Description

（関連出願の引用）
本願は、米国仮特許出願第６２／１１８，８８２号（２０１５年２月２０日出願、名称「Ｍｅｓｓａｇｅ Ｂｕｓ Ｓｅｒｖｉｃｅ Ｄｉｒｅｃｔｏｒｙ」）の利益を主張し、上記出願の内容は、参照により本明細書に引用される。

（既存のメッセージングベースのミドルウェアアーキテクチャ）
メッセージベースのミドルウェアは、通信サービス間の「メッセージ層」を提供し、したがって、各サービスが起動する下層動作環境を抽象化する。換言すると、「メッセージ層」は、サービスの間でメッセージを交換することにおいて仲介者としての役割を果たす。図１は、メッセージベースのミドルウェアの高レベル表現を示す。図１では、４つのサービスが、共通ミドルウェアプラットフォームを介して通信する。各サービスは、異なるプラットフォーム（例えば、ハードウェアプラットフォーム、オペレーティングシステム等）上で起動し得る。ミドルウェアは、それらがある定義されたメッセージングプロトコルを介して通信することができるように、各サービスの下層動作環境を抽象化する。

多くのメッセージベースのミドルウェアアーキテクチャがある。ミドルウェアアーキテクチャは、メッセージ待ち行列、パブリッシュ／サブスクライブ、およびメッセージブローカ等の特徴を含むことができる。ミドルウェア層は、メッセージ待ち行列の概念に基づくことができる。待ち行列ベースのミドルウェアアーキテクチャは、多くの異なる形態を成すことができ、いくつかある技法の中でも、メッセージを全てのサービスに送信するために使用される単一の共有待ち行列、各サービスがメッセージを受信するための専用待ち行列、または各サービスがメッセージを送信するための専用待ち行列があり得る。パブリッシュ／サブスクライブモデルでは、メッセージが、ミドルウェア内の宛先に送信（パブリッシュ）される。宛先は、メッセージ「トピック」（チャネルと呼ばれることもある）に依存する。特定のトピックに関連するメッセージを受信することを所望するサービスは、「トピック」にサブスクライブする。トピックは、メッセージタイプ（デバッグ、アラーム、警告、またはタスク要求）に関連し得る。メッセージブローカは、いくつかのトピック等を伴うパブリッシュ／サブスクライブアーキテクチャのように、いくつかの待ち行列を伴って実装され得る。メッセージブローカという用語は、全てのメッセージを受信し、全てのメッセージを配布するエンティティを一般的に指すメッセージバスの一部である。

（メッセージタイプ）
ミドルウェアブローカから、またはそこに送信されるメッセージは、いくつかの異なる方法で特徴付けられ得る。４つの一般的なタイプのメッセージは、送信メッセージ、受信メッセージ（ブロッキング）、受信メッセージ（非ブロッキング）、および通知である。送信メッセージは、サービスによってブローカに送信される。サービスがメッセージをブローカに送信すると、サービスは応答を期待せず、サービスの実行が継続する。ブロッキングメッセージは、サービスがメッセージを受信するまでサービスに一時停止（ブロック）させるであろうメッセージである。例えば、サービスがブローカまたは待ち行列からのメッセージを読み取ろうとし、メッセージが準備できていない場合、サービスの実行がブロッキングされるであろう。非ブロッキングメッセージは、メッセージが準備完了するまでサービスを一時停止（ブロック）させるないであろうメッセージである。例えば、サービスがブローカまたは待ち行列からのメッセージを読み取ろうとし、メッセージが準備できていない場合、サービスの実行は、メッセージが準備完了するまで継続するであろう。サービスは、非ブロッキング読み取りを試行するとき、それは、メッセージが準備できているときに呼び出され得るコールバック関数をブローカに提供し得る。通知メッセージは、ある前の要求の結果として、ブローカがサービスに送信するメッセージである。例えば、前の要求は、非ブロッキング読み取り試行またはサブスクライブ要求であり得る。

（メッセージバスプロトコル）
Ａｄｖａｎｃｅｄ Ｍｅｓｓａｇｅ Ｑｕｅｕｉｎｇ Ｐｒｏｔｏｃｏｌ（ＡＭＱＰ）は、メッセージバスプロトコルである。図２は、ＡＭＱＰの交換と待ち行列との間の関係を示す。ＡＭＱＰ交換は、サービスからメッセージを受理し、メッセージを１つ以上の待ち行列にルーティングする。交換は、静的ルール（例えば、メッセージをこれら５つのサービスに送信する）に基づいて、それら自体を交換に結合するあらゆる待ち行列に基づいて、メッセージトピックに基づいて、またはメッセージヘッダ内の値に基づいて、メッセージをルーティングするように設計されることができる。

Ｍｅｓｓａｇｅ Ｑｕｅｕｉｎｇ Ｔｅｌｅｍｅｔｒｙ Ｔｒａｎｓｐｏｒｔ（ＭＱＴＴ）（例えば、ＯＡＳＩＳ ＭＱＴＴＶ ３．１．１ Ｃｏｍｍｉｔｔｅｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ０１，１８ Ｍａｙ ２０１４を参照）は、メッセージベースのミドルウェアプロトコルである。ＭＱＴＴは、最も一般的にＦａｃｅｂｏｏｋ Ｍｅｓｓｅｎｇｅｒモバイルアプリで展開されている、制約されたデバイスならびに低帯域幅ネットワークに合った低オーバーヘッドメッセージ待ち行列およびトランスポートプロトコルである。それは、パブリッシュ／サブスクライブ（またはクライアント／サーバ）モデルを使用する。ＭＱＴＴの要素は、クライアント（パブリッシャおよびサブスクライバの両方であり得る）、サーバ（ブローカとも称される）、セッション、サブスクライブ、およびトピックである。ＨＴＴＰのように、ＭＱＴＴプロトコルは、それが２つの異なる役割（すなわち、クライアントおよびサーバ）を区別するという点で非対称である。

ＭＱＴＴ用語では、クライアントは、ＭＱＴＴを使用するプログラムまたはデバイスである。それは、常に、サーバへのネットワーク接続を確立する。クライアントは、
・ 他のクライアントが関心を持ち得るアプリケーションメッセージをパブリッシュすること
・ それが受信することに関心を持っているアプリケーションメッセージを要求するためにサブスクライブすること
・ アプリケーションメッセージに対する要求を除去するためにサブスクライブを解除すること
・ サーバから切断すること
を行うことができる。

ＭＱＴＴサーバは、クライアントからの接続を受理するエンティティである。ＨＴＴＰと異なり、これは、概して、いかなるアプリケーション論理も起動しないが、代わりに、ＭＱＴＴサーバが、アプリケーションメッセージをパブリッシュするクライアントと、それらを受信するようにサブスクライブしているクライアントとの間の仲介人としての役割を果たす。

トピックは、ＭＱＴＴでは「Ｑ」であり、パブリッシャをサブスクライバとリンクするためにサーバによって維持される名前を付けられたメッセージ待ち行列である。ＭＱＴＴクライアントは、ＰＵＢＬＩＳＨメッセージ（例えば、不透明なメッセージペイロードを、供給されたトピック名にサブスクライブした任意のクライアントに配信するための命令）をＭＱＴＴサーバに発行するときにパブリッシャの役割を担い、ＳＵＢＳＣＲＩＢＥメッセージ（例えば、供給されたトピックフィルタに一致する任意のＰＵＢＬＩＳＨメッセージを受信するための命令）をＭＱＴＴサーバに発行するときにサブスクライバの役割を担う。トピックフィルタは、１つ以上のトピックへの関心を示すためのサブスクライブにおいて含まれる表現である。トピックフィルタは、ワイルドカード性格を含み得る。ＰＵＢＬＩＳＨメッセージは、多くても１回、少なくても１回、正確に１回等の３つのＱｏＳ保証レベルのうちの１つを伴って配信される。

セッションおよびサブスクライブは、クライアントとサーバとの間の２つのアタッチレベルを表す。セッションは、クライアントとサーバとの間のステートフル相互作用（例えば、アクティブなＴＣＰ／ＩＰネットワーク接続）であり、固有のクライアント識別子によって識別される。セッションは、ＣＯＮＮＥＣＴメッセージをサーバに送信するクライアントによってのみ確立されることができる。ＣＯＮＮＥＣＴ、ＰＵＢＬＩＳＨ、およびＳＵＢＳＣＲＩＢＥメッセージ内のフラグは、セッションが切断される場合、どのようにしてセッション状態が維持されるかを決定する。

（ドメイン名システム（ＤＮＳ））
ドメイン名システム（ＤＮＳ）は、ＲＦＣ １０３５で定義されている。ＤＮＳは、あるタイプのメッセージバスまたはミドルウェアではないが、それは、インターネットもしくはプライベートネットワークに接続されるコンピュータ、サービス、または任意のリソースのための分散データベース上に構築される階層命名システムである。それは、ＩＰアドレスを参加エンティティの各々に割り当てられたドメイン名に関連付けるように設計される。

（ドメイン名システム−サービス発見（ＤＮＳ−ＳＤ））
ＤＮＳベースのサービス発見（ＤＮＳ−ＳＤ）は、あるタイプのメッセージバスまたはミドルウェアではないが、それは、ネットワークサービスの発見をサポートするために標準ＤＮＳプログラミングインターフェース、サーバ、およびパケットフォーマットを使用するプロトコルである。クライアントが探しているサービスのタイプとクライアントがそのサービスを探しているドメインとを与えられると、この機構は、クライアントが、標準ＤＮＳクエリを使用して、その所望のサービスの名前を付けられたインスタンスのリストを発見することを可能にする。

特定のサービスインスタンスが、ＲＦＣ ２７８２で議論されるようなＤＮＳサービス場所レコード（ＳＲＶ）およびＲＦＣ ６７６３で議論されるようなＤＮＳテキストレコード（ＴＸＴ）を使用して、記述されることができる。ＳＲＶレコードは、「＜Ｉｎｓｔａｎｃｅ＞．＜Ｓｅｒｖｉｃｅ＞．＜Ｄｏｍａｉｎ＞」という形態の名前を有し、サービスインスタンスが到達されることができる標的ホストおよびポートを与える。同一名のＤＮＳ ＴＸＴレコードは、キー／値ペア（例えば、ｓｃｌ＝＜ｕｒｉ＿ｐａｔｈ＿ｔｏ＿ｓｃｌＢａｓｅ＞）を使用する構造化形態で、このインスタンスについての追加の情報を与える。クライアントは、前述のＤＮＳ ＳＲＶ／ＴＸＴレコードペアの名前であるゼロ以上の名前の組を返す、「＜Ｓｅｒｖｉｃｅ＞．＜Ｄｏｍａｉｎ＞」という形態の名前を伴う、ＲＦＣ ６７６３で議論されるようなＤＮＳポインタレコード（ＰＴＲ）に対するＤＮＳクエリを使用して、所与のサービスタイプの利用可能なインスタンスのリストを発見する。次いで、クライアントは、ＳＲＶ／ＴＸＴレコードペアを読み出し、これらの記録内に含まれる発見情報を入手するために、第２のＤＮＳクエリを行うことができる。この発見されたホスト、ポート、および追加の発見情報を使用して、次いで、クライアントは、着目サービスにアクセスすること／それを呼び出すことができる。

（ｏｎｅＭ２Ｍサービス層）
サービス層は、どのようにしてサービスがアプリケーションおよび他のサービスと相互作用するかを定義するプロトコルの組である。ｏｎｅＭ２Ｍサービス層は、共通機能（またはサービス能力）の組として編成され、そのインスタンス化は、ｏｎｅＭ２Ｍ ＴＳ−０００１ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅで議論されるように、共通サービスエンティティ（ＣＳＥ）と称される。これらの共通機能は、図３および図４に示されるように、Ｍｃａ、Ｍｃｃ、およびＭｃｎ参照点を介してエクスポーズされる。図４は、Ｍｓｃ参照点も強調表示する。Ｍｓｃ参照点は、異なるサービスコンポーネントのサービス能力間の相互作用の組を規定する。サービス能力間の相互作用の実現は、ｏｎｅＭ２Ｍ ＴＳ−０００７ Ｓｅｒｖｉｃｅ Ｃｏｍｐｏｎｅｎｔ Ａｒｃｈｉｔｅｃｔｕｒｅで議論されるように実装特定である。

Ｍｃａ参照点が、アプリケーションエンティティ（ＡＥ）とＣＳＥとの間の通信フローを指定する一方で、Ｍｃｃ参照点は、同一のＭ２Ｍサービスプロバイダドメイン内の２つのＣＳＥ間の通信フローを指定する。ＭｃａおよびＭｃｃを横断する通信は、ペアリングされた要求／応答メッセージを介して行われ、各要求は、標的ＣＳＥ上でホストされるリソースに特定のＲＥＳＴｆｕｌ動作（例えば、Ｃｒｅａｔｅ、Ｒｅｔｒｉｅｖｅ、Ｕｐｄａｔｅ、Ｄｅｌｅｔｅ）を行う。Ｍｃｃ’は、異なるＭ２Ｍ ＳＰのインフラストラクチャドメイン内に位置するＣＳＥ間で使用される。Ｍｃｎは、トランスポートおよびコネクティビティ以外のサービスのために、ＣＳＥと下層ネットワークサービスエンティティ（ＮＳＥ）との間で使用される。

ＣＳＥは、「ノード」と称されるアーキテクチャのエンティティ上でホストされる。ノードは、ａ）１つのＣＳＥおよびゼロ以上のＡＥ、または、ｂ）１つ以上のＡＥを含む、機能的エンティティである。ＣＳＥによって提供されるサービスは、低コストデバイス上で実装される温度センササービスから、大型ネットワークサーバ上で展開される課金システムまで様々であり得る。したがって、アーキテクチャは、メッセージングプロトコルを利用するために好適である。

本明細書では、我々が「オープンメッセージバス」（ＯＭＢ）と称するメッセージングシステムアーキテクチャが提示される。ＯＭＢは、サービス間のコネクティビティおよび通信を促進するメッセージングシステムインフラストラクチャである。ＯＭＢバックボーンは、ＯＭＢに接続する全てのサービスによって活用されることができるいくつかのインフラストラクチャサービスを提供する。

ＯＭＢインフラストラクチャは、サービスディレクトリおよび発見サービスを提供する。発見サービスは、どのようなサービスがＯＭＢを介して利用可能であるかを分類し、サービスが通信するためにいずれのプロトコルを要求するか、サービスにアクセスすることに関連付けられるコスト等の追加の詳細を提供するサービスディレクトリまたはデータベースをクライアントがブラウズすることを可能にする。ＯＭＢは、どのようなサービスが着目されるＯＭＢ上で利用可能であるかを動的に発見するためにサービスが使用し、次いで、ＯＭＢに接続し、これらの発見されたサービスと通信するために発見中に取得された情報を使用することができるＤＮＳ−ＳＤインターフェースを提供する。

サービスがＯＭＢに参入すると、サービスディレクトリにサブスクライブし、特定のサービスまたは特定のクラスのサービスが接続するとき、またはＯＭＢから切断するときに通知を受信することができる。

ＯＭＢは、トランスポートに依存しないＡＰＩを利用し得る。ＡＰＩは、サービスが、バスに接続し、異なる下層トランスポートおよびアプリケーションレベルプロトコルを使用する他のサービスと通信するために、任意の下層トランスポートおよびアプリケーションレベルプロトコル（ＵＤＰ、ＣｏＡＰ、ＴＣＰ、ＷｅｂＳｏｃｋｅｔｓ、ＨＴＴＰ等）を使用することができるように設計される。

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の一連の概念を導入するように提供される。本概要は、請求される主題の主要な特徴または不可欠な特徴を識別することを意図せず、請求される主題の範囲を限定するために使用されることも意図していない。さらに、請求される主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に制約されない。

添付の図面と併せて一例として挙げられる、以下の説明から、より詳細に理解され得る。
図１は、メッセージベースのミドルウェアの例示的高レベル表現を図示する。 図２は、ＡＭＱＰ交換と待ち行列との間の例示的関係を図示する。 図３は、例示的ｏｎｅＭ２Ｍ機能的アーキテクチャを図示する。 図４は、例示的ｏｎｅＭ２Ｍ機能的アーキテクチャを図示する。 図５は、例示的オープンメッセージバスアーキテクチャを図示する。 図６は、オープンメッセージバスアーキテクチャで動作する例示的サービスディレクトリを図示する。 図７は、オープンメッセージバスアーキテクチャで動作する例示的データベースサービスを図示する。 図８は、オープンメッセージバスアーキテクチャで動作する例示的管理サービスを図示する。 図９は、サービス／ＯＭＢ ＡＰ／ＯＭＢクライアント関係を伴うオープンメッセージバスアーキテクチャの例示的エンドツーエンド通信を図示する。 図１０は、例示的ＤＮＳ−ＳＤベースのサービス発見メッセージフローを図示する。 図１１は、オープンメッセージバスアーキテクチャの１つ以上のコンポーネントを使用する、メッセージングの例示的概観を図示する。 図１２は、サービスディレクトリへのサービス発見情報のパブリッシュのための例示的メッセージフローを図示する。 図１３は、ＤＮＳ−ＳＤベースの発見のための例示的メッセージフローを図示する。 図１４は、ＡＭＱＰ接続を開くことの例示的メッセージフローを図示する。 図１５は、メッセージバスバックボーンの１つ以上のコンポーネントを使用して、発見されたサービスと通信するための例示的方法フローを図示する。 図１６は、ＯＭＢアーキテクチャを使用して、どのようにしてｏｎｅＭ２Ｍサービス（ＣＳＦ）またはサービスコンポーネント（例えば、サービスのグループ）が展開され得るかという例示的実装を図示する。 図１７Ａは、開示される主題が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムの系統図である。 図１７Ｂは、図１７Ａで図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。 図１７Ｃは、図１７Ａで図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。 図１７Ｄは、図１７Ａの通信システムの側面が具現化され得る、例示的コンピューティングシステムのブロック図である。 図１８は、メッセージバスサービスディレクトリに関連付けられる、例示的ユーザインターフェースを図示する。

本明細書では、サービスの間のコネクティビティおよび通信を促進する、メッセージングバス（「オープンメッセージバス」（ＯＭＢ）とも称される）が議論される。開示されるメッセージングバスは、メッセージングバスと接続するサービスによって活用され得るインフラストラクチャサービスを提供する。

Ａｄｖａｎｃｅｄ Ｍｅｓｓａｇｅ Ｑｕｅｕｉｎｇ Ｐｒｏｔｏｃｏｌ（ＡＭＱＰ）およびＭｅｓｓａｇｅ Ｑｕｅｕｉｎｇ Ｔｅｌｅｍｅｔｒｙ Ｔｒａｎｓｐｏｒｔ（ＭＱＴＴ）等の従来のメッセージングバスプロトコルは、どのようなサービスがメッセージバス上で利用可能であるかを動的に発見するための組み込みのサポートを有していない。したがって、メッセージバスに接続されるサービスは、どのような他のサービスがメッセージバス上にあるかを認識しない場合がある。これは、メッセージバスのサービスの過小利用をもたらし得る。例えば、ホームオートメーションサービスプロバイダは、地元の気象状態についての情報を提供するサービス接続することが可能である場合、家庭暖房および冷房システムをより効率的に管理することが可能であり得る。ＡＭＱＰおよびＭＱＴＴは、ホームオートメーションプロバイダが気象サービスを動的に発見して使用する手段を提供しない。

ＯＭＢインフラストラクチャは、発見サービスを備えているサービスディレクトリを提供し得る。発見サービスは、どのようなサービスがＯＭＢを介して利用可能であるかを分類するサービスディレクトリまたはデータベースをクライアントがブラウズすることを可能にする。発見サービスは、とりわけ、サービスが通信するためにどのプロトコルを要求するか、またはサービスにアクセスすることに関連付けられるコスト等の追加の詳細も提供し得る。実施例では、ＯＭＢは、ＤＮＳ−ＳＤインターフェースを提供し、サービスは、それを使用して、そのサービスが着目するどんなサービスがＯＭＢ上で利用可能であるかを動的に発見し、次いで、ＯＭＢに接続し、これらの発見されたサービスと通信するために発見中に取得された情報を使用することができる。

サービスがＯＭＢに参入すると、それは、ＯＭＢクライアントと称され得る。ＯＭＢクライアントは、サービスディレクトリにサブスクライブし、特定のサービス（特定のクラスのサービスを含む）が接続するとき、もしくはそれがＯＭＢから切断するとき、通知を受信することができる。

ＯＭＢは、トランスポートに依存しないアプリケーションプログラミングインターフェース（ＡＰＩ）を利用し得る。ＡＰＩは、サービスが、バスに接続し、異なる下層トランスポートおよびアプリケーションレベルプロトコルを使用する他のサービスと通信するために、任意の下層トランスポートおよびアプリケーションレベルプロトコル（ＵＤＰ、ＣｏＡＰ、ＴＣＰ、ＷｅｂＳｏｃｋｅｔｓ、ＨＴＴＰ、ＡＭＱＰ、ＭＱＴＴ、ＸＭＰＰ等）を使用することができるように設計される。

図５は、ＯＭＢアーキテクチャ２０１の例示的説明図である。ＯＭＢアーキテクチャ２０１は、メッセージブローカ２０３と、サービスディレクトリ２１０もしくは他のサービス２０４等の１つ以上のメッセージバスバックボーン２０２サービス（すなわち、本明細書でさらに詳細に議論されるインフラストラクチャサービス）とを含むメッセージバスバックボーン２０２を有する。他のサービス２０４は、それぞれ、図７および図８に示されるように、とりわけ、データベースサービス２４０と、管理サービス２５０とを含み得る。本明細書でさらに詳細に議論されるデータベースサービス２４０は、情報を記憶し、クエリを行うために、サービスによって使用され得る。管理サービス２５０は、メッセージバスバックボーン２０２と接続するクライアントサービスを管理および監視するために使用され得る。

サービスディレクトリ２１０は、メッセージブローカ２０３と接続されているサービスの動的発見およびパブリッシュのために使用され得る。サービスディレクトリ２１０は、ＤＮＳ−ＳＤインターフェース２１１ならびにＯＭＢ ＡＰＩ ２１２をサポートする。ＤＮＳ−ＳＤインターフェース２１１は、場所追跡デバイス２２０がメッセージブローカ２０３に登録する前、またはそれと接続する前にメッセージブローカ２０３と接続される利用可能なサービスをブラウズするために、第１のサービス（例えば、場所追跡デバイス２２０）によって使用されることができる。場所追跡デバイス２２０がメッセージブローカ２０３に登録されると、ＯＭＢ ＡＰＩ ２２５が、メッセージバスバックボーン２０２に関連付けられるサブスクライブまたは通知機構を利用するために使用されることができる。サブスクライブは、イベントＸが起こるときを知ることを所望することをサービスが示すときである。通知は、イベントＸが起こったことをサービスが伝えられるときである。サブスクライブまたは通知機構は、ＤＮＳ−ＳＤインターフェース２１１上で利用可能でないこともある。サブスクライブまたは通知機構は、場所追跡デバイス２２０等のサービスが、他のサービスに関する通知を受信するためにサービスディレクトリ２１０にサブスクライブすることを可能にする。例えば、場所追跡デバイス２２０は、場所追跡デバイス２２０が関心を持つサービスがバスと接続または切断するとき、通知を受信するためにサブスクライブすることができる。サービスディレクトリ２１０およびサブスクライブまたは通知機構（例えば、図６のサブスクライブまたは通知２１３）は、本明細書でさらに詳細に説明される。

本明細書でさらに詳細に議論されるように、サービスは、ＯＭＢクライアント２２２等のＯＭＢクライアントを介してメッセージバックボーン２０２とインターフェースをとり、ＯＭＢクライアントは、サービスとＯＭＢによって使用される下層トランスポート（例えば、ＡＭＱＰ、ＵＤＰ、ＭＱＴＴ、ＸＭＰＰ、ＷｅｂＳｏｃｋｅｔｓ等）との間の抽象化の層（ＡＰＩ）を提供する。

ＯＭＢアーキテクチャ２０１およびそのトランスポートに依存しないＡＰＩ（例えば、ＯＭＢ ＡＰＩ ２２５）は、設計が規模調整されることを可能にする。設計は、大型展開（例えば、クラウドインフラストラクチャ）からより小型の展開（例えば、ホームゲートウェイ）まで適応する。例えば、サービスが多くの遠隔サーバ上でホストされるクラウドベースの展開から、全てのサービスが個々のデバイス、例えば、低複雑性温度センサ上でホストされる展開まで及ぶ。

図６は、ＯＭＢアーキテクチャ２０１で動作する例示的サービスディレクトリ２１０を図示する。サービスディレクトリ２１０は、とりわけ、ＯＭＢクライアント２１４、ＤＮＳ−ＳＤインターフェース２１１と接続されるＤＮＳ−ＳＤサーバ２１８、サービスパブリッシャマネージャ２１７、サービス発見クエリマネージャ２１６、サブスクライブまたは通知マネージャ２１３、およびサービス発見レコード記憶装置２１５をサポートすることができる。サービスパブリッシャマネージャ２１７は、サービス作成要求を受理する。それは、サービスディレクトリ２１０内の新しいサービスプロファイルに入力するために使用され得る。サービス発見クエリマネージャ２１６は、他のサービスからサービスクエリを受理し、要求サービスがサービスディレクトリ２１０内にあるかどうかをチェックする。サブスクライブ／通知マネージャ２１３は、他のサービスからサブスクライブ要求を受理し、新しいサービスがサービスディレクトリ２１０に入力されるとき、要求通知を生成し得る。ＤＮＳ−ＳＤインターフェース２１１は、メッセージブローカ２０３またはメッセージバックボーン２０２の他の部分にアクセスすることなく、サービス（例えば、場所追跡デバイス２２０）がサービスディレクトリ２１０をブラウズすることを可能にする。ＤＮＳ−ＳＤインターフェース２１１は、場所追跡デバイス２２０がメッセージバックボーン２０２と接続すべきかどうかを決定する前に、場所追跡デバイス２２０（または他のサービス）が、どのようなサービスがメッセージバックボーン２０２を介して提供されるかを動的に決定することを所望するとき、特に有用であり得る。

サービスプロファイル（例えば、サービスプロファイル２１９）は、サービス（例えば、場所追跡デバイス２２０または場所追跡サービス２３０）を記述する、ＰＴＲ、ＳＲＶ、およびＴＸＴレコードから成る。サービスプロファイル２１９は、メモリに常駐するであろうテーブル内の入力であろう。ＯＭＢ ＡＰＩ（例えば、ＯＭＢ ＡＰＩ ２２５またはＯＭＢ ＡＰＩ ２１２）は、サービスプロファイルがサービスディレクトリ２１０に登録されることを可能にし、発見または検索動作がサービスディレクトリ２１０に行われることを可能にし、他のＯＭＢクライアント（例えば、ＯＭＢクライアント２２２）がサブスクライブ要求をサービスディレクトリ２１０に発行することを可能にする。サブスクライブ要求は、特定のサービスがサービスディレクトリ２１０に登録する（または登録解除する）ときに通知を要求するために使用され得る。

本明細書の以降（例えば、表３）で、サービスディレクトリ２１０に関連付けられるＯＭＢコールのリストが提示される。ｏｍｂＣｏｎｆｉｇ（）ＡＰＩは、サービスプロファイル２２３がサービスディレクトリ２１０にロードされることを可能にする。例えば、ｏｍｂＣｏｎｆｉｇ（）ＡＰＩは、ネットワーク管理者がサービスディレクトリ２１０にサービスのプロファイル（例えば、場所追跡デバイス２２０のためのサービスプロファイル２２３）をロードするために管理サービス２５０を使用することを所望するとき、使用され得る。代替として、場所追跡デバイス２２０は、独自のサービスプロファイル２２３をサービスディレクトリ２１０にロードするためにｏｍｂＣｏｎｆｉｇ（）ＡＰＩを使用することができる。例えば、場所追跡デバイス２２０のためのサービスプロファイル２２３がネットワーク管理者によってロードされるとき、場所追跡デバイス２２０は、そのサービスプロファイル２２３をフェッチし、（そのＯＭＢクライアント２２２を介して）メッセージブローカ２０３と適切に接続し、それを構成する方法を習得するとともに、それが依存する他のサービスを決定するために、ｏｍｂＣｏｎｆｉｇ（）ＡＰＩを使用し得る。

ＯＭＢ ＡＰＩ ２１２は、サービスディレクトリ２１０が、他のＯＭＢサービスからパブリッシュ、サブスクライブ、および発見作成要求を受信すること、ならびに通知を他のＯＭＢサービスに送信することを可能にする。サブスクライブまたは通知特徴は、メッセージバスバックボーン２０２（またはサービスに関連付けられるＯＭＢクライアント）の１つ以上のコンポーネントと接続される他のサービスが、サービスディレクトリ２１０にサブスクライブし、規定基準（例えば、特定のタイプのサービスがサービスディレクトリプロファイルを作成、更新、または削除した）に基づく通知を受信することを可能にする。本明細書で使用されるようなサービスディレクトリプロファイルは、サービスプロファイルと見なされることに留意されたい。

サービスディレクトリ２１０は、ＤＮＳ−ＳＤレコードタイプ（ＰＴＲ、ＳＲＶ、およびＴＸＴ）を使用して、データベース内にサービスプロファイル２１９を記憶する。メッセージブローカ２０３（すなわち、ＯＭＢサービス）と接続される各サービスのサービスプロファイルは、管理コンソール（管理サービス２５０）を介して、静的もしくは動的のいずれかで、またはＯＭＢサービスのｏｍｂＣｏｎｆｉｇ（）ＡＰＩの使用によって動的に、ＤＮＳ−ＳＤサーバ２１８の中にプロビジョニングされる。これらのレコードは、表１に列挙されるサービス発見および構成情報で構成される。

各サービスは、サービスＩＤおよびサービスタイプを割り当てられ得る。サービスＩＤは、ＤＮＳ−ＳＤサービスタイプにマップされ、ＯＭＢサービスのＤＮＳ−ＳＤベースの発見（例えば、特定のタイプのｏｎｅＭ２ＭサービスまたはＥＴＳＩ Ｍ２Ｍサービス）を行うために使用されることができる。識別子は、追加のＤＮＳ−ＳＤサービスサブタイプも、追加の粒度（例えば、サービスの能力にマップされることができるサブサービス）を提供するために定義され得るように、フォーマットされて使用され得る。

ＤＮＳ−ＳＤ ＳＲＶレコードが、サービスディレクトリ２１０にロードされる各ＯＭＢサービス（例えば、場所追跡デバイス２２０または場所追跡サービス２３０）のために、随意に、ＯＭＢサービスによってサポートされる個々の特徴（例えば、２つの別個の領域の場所カバレッジ）のために、ＤＮＳ−ＳＤサーバ２１８上で作成されるであろう。ＳＲＶレコード構文は、サービスならびにサブサービスを定義することをサポートする。この構文は、（サブサービスとして）特徴を規定するために使用されることができる。次いで、ＤＮＳ−ＳＤインターフェース２１１は、所与のサービスタイプ（例えば、特定のｏｎｅＭ２ＭサービスまたはＥＴＳＩ Ｍ２Ｍサービス）の利用可能なインスタンスのリストを発見するために、ＤＮＳ ＰＴＲレコードルックアップを行うために使用されることができる。ＤＮＳ ＰＴＲルックアップへの応答は、一致するインスタンス名のリストである。サービスタイプインスタンスのためのＤＮＳ−ＳＤ ＰＴＲレコードは、ｓｅｒｖｉｃｅ．ｐｒｏｔｏ．ｄｏｍａｉｎ ＰＴＲ ｉｎｓｔａｎｃｅ．ｓｅｒｖｉｃｅ．ｐｒｏｔｏ．ｄｏｍａｉｎというフォーマットを有し得る。ＯＭＢサービスサブタイプインスタンスのためのＤＮＳ−ＳＤ ＰＴＲレコードは、以下のフォーマットを有し得る。
● ｓｕｂ−ｓｅｒｖｉｃｅ．ｓｅｒｖｉｃｅ．ｐｒｏｔｏ．ｄｏｍａｉｎ ＰＴＲ ｉｎｓｔａｎｃｅ．ｓｕｂ−ｓｅｒｖｉｃｅ．ｓｅｒｖｉｃｅ．ｐｒｏｔｏ．ｄｏｍａｉｎ
○ ｓｕｂ−ｓｅｒｖｉｃｅは、サブサービス名が後に続く、下線文字から成る（例えば、＿ｈｄｒ）。

○ ｓｅｒｖｉｃｅは、サービスプロトコル名が後に続く、下線文字から成る（例えば、＿ｅｔｓｉＭ２Ｍ）。このフィールドは、いずれのプロトコルがサービスと通信するために要求されるかを検索エンティティがチェックすることを可能にする。

○ ｐｒｏｔｏは、下線と、「＿ｔｃｐ」（ＴＣＰを経由して起動するアプリケーションプロトコルのため）または「＿ｕｄｐ」（他の全てのため）のいずれかとから成る。

○ ｄｏｍａｉｎは、サービス名が登録されるＤＮＳサブドメインを規定する。それは、「ｌｉｎｋ−ｌｏｃａｌ ｄｏｍａｉｎ」を意味する「ｌｏｃａｌ．」であり得るか、または、それは、非ローカルＤＮＳドメイン名（例えば、「ｃｏｍ」）であり得る。
● ＰＴＲは、ＤＮＳ ＰＴＲレコードで使用されるＤＮＳキーワードである。
● ｉｎｓｔａｎｃｅは、サービスインスタンスに割り当てられる使いやすい名前（例えば、ＯＭＢサービスインスタンスの名前）である。

タイプ「ｅｔｓｉＭ２Ｍ」および「ｅｘａｍｐｌｅ．ｃｏｍ」と名付けられたドメイン内でホストされるインスタンス名「ｎｒａｒ０１」のＯＭＢサービスインスタンスのための例示的ＰＴＲレコードが、以下のように示される：ｎｒａｒ．ｅｔｓｉＭ２Ｍ．＿ｔｃｐ．ｅｘａｍｐｌｅ．ｃｏｍ．ＰＴＲｎｒａｒ０１．＿ｎｒａｒ．＿ｅｔｓｉＭ２Ｍ．＿ｔｃｐ．ｅｘａｍｐｌｅ．ｃｏｍ。

ＤＮＳ−ＳＤは、サービスインスタンスが到達されることができる標的ホスト名またはアドレスと、ポートとを定義するために、ＤＮＳ ＳＲＶレコードを使用する。ＩＰベースのアドレスがＯＭＢサービスの間で使用されないので、ＳＲＶレコードは、必ずしもクライアントを発見されたサービスに向けさせないであろう。ＳＲＶレコードは、バスに参入し、メッセージバスバックボーン２０２の１つ以上のコンポーネントと通信するために使用されることができるアドレス／ポート／プロトコルの組み合わせのリストにサーチャを向けさせることができる。サーチャのＯＭＢクライアント２２２は、メッセージバスバックボーン２０２に接続し、発見されたサービスと通信するために、これらのアドレス／ポート／プロトコルの組み合わせのうちの１つを使用することができる。ＯＭＢサービスインスタンスのためのＳＲＶレコードは、ｓｅｒｖｉｃｅ．＿ｐｒｏｔｏ．ｄｏｍａｉｎ ＴＴＬ ｃｌａｓｓ ＳＲＶ ｐｒｉｏｒｉｔｙ ｗｅｉｇｈｔ ｐｏｒｔ ｔａｒｇｅｔというフォーマットを有し得る。ＯＭＢサービスサブタイプインスタンスのためのＳＲＶレコードは、ｓｕｂ＿ｓｅｒｖｉｃｅ．＿ｓｅｒｖｉｃｅ．＿ｐｒｏｔｏ．ｄｏｍａｉｎ ＴＴＬ ｃｌａｓｓ ＳＲＶ ｐｒｉｏｒｉｔｙ ｗｅｉｇｈｔ ｐｏｒｔ ｔａｒｇｅｔというフォーマットを有する。用語は、以下のように説明され得る。
・ ｓｕｂ＿ｓｅｒｖｉｃｅ：所望のサブサービスの記号名。
・ ｓｅｒｖｉｃｅ：所望のサービスの記号名。
・ ｐｒｏｔｏ：所望のサービスのトランスポートプロトコル。これは、通常、ＴＣＰまたはＵＤＰのいずれかである。
・ ｄｏｍａｉｎ：このレコードが有効であるドメイン名。
・ ＴＴＬ：標準ＤＮＳ有効期間フィールド。
・ ｃｌａｓｓ：標準ＤＮＳクラスフィールド（これは、常に、「インターネット」を表す「ＩＮ」の値に設定される）。
・ ｐｒｉｏｒｉｔｙ：標的ホストの優先順位、より低い値は、より好ましいことを意味する。
・ ｗｅｉｇｈｔ：同一の優先順位を伴うレコードに対する相対的重み。
・ ｐｏｒｔ：サービスが見出されるＴＣＰまたはＵＤＰポート。
・ ｔａｒｇｅｔ：サービスを提供するマシンの正規のホスト名。
タイプ「ｅｔｓｉＭ２Ｍ」およびインスタンス名「ｎｒａｒ０１」のＯＭＢサービスインスタンスのための例示的ＳＲＶレコードは、＿ｅｔｓｉＭ２Ｍ．＿ｔｃｐ．ｅｘａｍｐｌｅ．ｃｏｍ．８６４００ ＩＮ ＳＲＶ ０ ５ ５０６０ ｎｒａｒ０１．ｅｘａｍｐｌｅ．ｃｏｍである。

サービスディレクトリ２１０のためのＤＮＳ−ＳＤ ＴＸＴレコードも、（例えば、管理ツール２５０によって）各ＯＭＢサービスのためにＤＮＳ−ＳＤサーバ上で作成されることができる。ＤＮＳ−ＳＤは、名前を付けられたサービスについての追加の情報を伝える名前／値ペアを記憶するために、ＤＮＳ ＴＸＴレコードを使用する。各名前／値ペアは、「ｎａｍｅ＝ｖａｌｕｅ」の形態で、ＤＮＳ ＴＸＴレコード内の独自の構成文字列としてエンコードされる。最初の「＝」記号までの全てが、名前である。（存在する場合、後続の「＝」記号を含む）文字列の終わりまでの最初の「＝」記号の後の全てが、値である。サービスディレクトリ２１０の観点から、ＤＮＳ−ＳＤ ＴＸＴレコードは、ＯＭＢサービスの有用な属性情報を記憶するために使用されることができる。例えば、ＤＮＳ−ＳＤ ＴＸＴレコードは、以下等の属性名／値ペアを含み得る。
● ＳＥＲＶＩＣＥ＿ＩＤ＝１２３４５
● ＳＥＲＶＩＣＥ＿ＴＹＰＥ＝ＮＡＥ
● ＳＥＲＶＩＣＥ＿ＮＡＭＥ＝ＮＡＥ０１
● ＢＲＯＫＥＲ＿ＩＰ＿ＯＰＴＩＯＮ＿１＝１７２．２５．０．２３０
● ＢＯＲＫＥＲ＿ＰＯＲＴ＿ＯＰＴＩＯＮ＿１＝５６７２
● ＯＭＢ＿ＰＲＯＴＯＣＯＬ＿ＴＹＰＥ＿ＯＰＴＩＯＮ＿１＝ＡＭＱＰ
● ＢＲＯＫＥＲ＿ＩＰ＿ＯＰＴＩＯＮ＿２＝１７２．２５．０．２３１
● ＢＯＲＫＥＲ＿ＰＯＲＴ＿ＯＰＴＩＯＮ＿２＝５６７３
● ＯＭＢ＿ＰＲＯＴＯＣＯＬ＿ＴＹＰＥ＿ＯＰＴＩＯＮ＿２＝ＨＴＴＰ
● ＳＥＬＦ＿ＥＸＨＡＮＧＥ＿ＮＡＭＥ＝ＮＡＥ０１＿ＥＸ
● ＳＥＬＦ＿ＲＯＵＴＩＮＧ＿ＫＥＹ＝ＮＡＥ０１＿ＲＫ
● ＳＥＬＦ＿ＱＵＥＵＥ＝ＮＡＥ０１＿Ｑ
● ＳＤ＿ＥＸＣＨＡＮＧＥ＿ＮＡＭＥ＝ＳＤ０１＿ＥＸ
● ＳＤ＿ＲＯＵＴＩＮＧ＿ＫＥＹ＝ＳＤ０１＿ＲＫ
● ＧＤＩ＿ＥＸＣＨＡＮＧＥ＿ＮＡＭＥ＝ＧＤＩ０１＿ＥＸ
● ＧＤＩ＿ＲＯＵＴＩＮＧ＿ＫＥＹ＝ＧＤＩ０１＿ＲＫ
● ＲＥＱＤ＿ＳＥＲＶＩＣＥＳ＝ＳＤ，ＧＤＩ，ＮＲＡＲ，ＮＳＥＣ，ＮＨＤＲ
ＯＭＢサービス構成は、サービス（例えば、場所追跡デバイス２２０）がメッセージブローカ２０３と接続し、その上で通信することができるように、サービスが、それ自体についての情報をＯＭＢクライアント（例えば、ＯＭＢクライアント２２２）に提供するプロセスを指す。構成中に提供される情報は、表１（上記）に示される。本明細書で議論されるアーキテクチャは、ＯＭＢサービス構成のための複数の方法をサポートする。第１の方法は、構成ファイルの使用のみに依拠する。第２の方法は、ＤＮＳ ＴＸＴレコードルックアップと結合される構成ファイルに依拠する。第１の方法に対して、この情報の全ては、サービス（例えば、場所追跡サービス２３０）内に記憶されるＯＭＢサービス構成のためのファイル内に含まれる。例では、場所追跡デバイス２２０は、ＡＰＩコールを介して、この構成ファイルをＯＭＢクライアント２２２にパスする。第１の方法が使用されるとき、ｏｍｂＣｏｎｆｉｇ（）ＡＰＩコールは、メッセージブローカ２０３への動作をもたらさず、ファイルは、単に、ＯＭＢクライアント２２２にパスされる。しかしながら、ＯＭＢクライアント２２２が場所追跡デバイス２２０についての情報で構成されると、場所追跡デバイス２２０は、メッセージバスバックボーン２０２の一部（例えば、メッセージブローカ２０３）に登録するために、ｏｍｂＲｅｇｉｓｔｅｒ（）ＡＰＩコールを使用し得る。ｏｍｂＲｅｇｉｓｔｅｒ（）ＡＰＩおよびｏｍｂＣｏｎｆｉｇ（）ＡＰＩは、表において、および図１２のコールフローに関する議論において、本明細書でさらに詳細に議論される。

第２の方法に対して、表１内の情報は、２つの別個のファイルに記憶される。第１のファイルは、ＤＮＳ情報（表１の最初の４行）を記憶し、サービス（例えば、場所追跡デバイス２２０）内に記憶される。例では、場所追跡デバイス２２０は、この第１のファイルをＯＭＢクライアント２２２にパスし、それは、ｏｍｂＣｏｎｆｉｇ（）ＡＰＩコールを介して行われ得る。残りの情報は、サービスディレクトリ２１０の中でプロビジョニングされるＤＮＳ ＴＸＴレコード内に記憶される。ＯＭＢクライアント２２２は、ＤＮＳ ＴＸＴレコードルックアップを介して、残りの情報を読み出す。

図１０−図１５に図示されるステップを行うエンティティは、論理エンティティであり得ることを理解されたい。ステップは、図１７Ｃまたは図１７Ｄに図示されるもの等のデバイス、サーバ、またはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行し得る。例では、Ｍ２Ｍデバイスの相互作用に関しては以下にさらに詳述されるが、図１１の場所追跡サービス２３０および場所追跡デバイス２２０が、図１７Ａの１つ以上のＭ２Ｍ端末デバイス１８上に常駐し得る一方で、図１１のメッセージブローカ２０３、サービスディレクトリ２０１、およびＤＮＳ−ＳＤサーバ２１１ならびにＯＭＢ ＡＰインターフェース２１２は、図１７ＡのＭ２Ｍゲートウェイデバイス１４上に常駐し得る。これは、一例にすぎない。

図１０は、サービス（例えば、場所追跡デバイス２２０）がサービスディレクトリ２１０をブラウズするためにＤＮＳ−ＳＤを使用する、プロセスの例示的説明図である。この例では、場所追跡デバイス２２０は、ＥＴＳＩネットワークアプリケーションイネーブルメント（ＮＡＥ）サービスを検索する。ｏｎｅＭ２Ｍの例では、場所追跡デバイス２２０は、ｏｎｅＭ２Ｍデバイス管理（ＤＭＧ）サービスを検索する。ステップ２８０では、場所追跡デバイス２２０は、マルチキャストが使用されない場合、ローカルサービスディレクトリサーバ（例えば、サービスディレクトリ２１０）のユニキャストアドレスで構成される。ステップ２８１では、サービスディレクトリ２１０は、メッセージブローカ２０３にアタッチされたサービスのためにプロビジョニングされるＤＮＳ−ＳＤサービス発見レコード（ＰＴＲ、ＳＲＶ、およびＴＸＴ）を有する。ステップ２８２では、場所追跡デバイス２２０は、ＮＡＥ ＰＴＲレコードに対するＤＮＳ−ＳＤルックアップを送信する。ステップ２８３では、サービスディレクトリ２８３は、ＤＮＳ−ＳＤ応答（例えば、ａｎｅ０１．＿ｎａｅ．＿ｅｔｓｉＭ２Ｍ．＿ｔｃｐ．ｃｏｍ）を場所追跡デバイス２２０に送信する。ステップ２８４では、場所追跡デバイス２２０は、解決すべき所望のＮＡＥ ＰＴＲレコードを選択する。ステップ２８５では、場所追跡デバイス２２０は、選択されたサービスのためのＳＲＶレコード（例えば、ｎａｅ０１．ｎａｅ．＿ｅｔｓｉＭ２Ｍ．＿ｔｃｐ．ｃｏｍ）に対するＤＮＳ−ＳＤルックアップを送信する。ステップ２８６では、サービスディレクトリ２１０は、ＤＮＳ−ＳＤ応答（例えば、ｎａｅ０１．ｅｘａｍｐｌｅ．ｃｏｍＦＱＤＮ，ｎａｅ０１．＿ｎａｅ．＿ｅｔｓｉＭ２Ｍ．＿ｔｃｐ．ｃｏｍを含むＳＲＶレコード）を送信する。このＳＲＶレコードは、バスに参入し、ＯＭＢと通信するために使用されることができるアドレス／ポート／プロトコル組み合わせのリストを場所追跡デバイス２２０に提供する。ステップ２８７では、場所追跡デバイス２２０は、ＴＸＴレコード（例えば、ｎａｅ０１．ｅｘａｍｐｌｅ．ｃｏｍ）に対するＤＮＳ−ＳＤルックアップを送信する。ＤＮＳ ＴＸＴレコードは、サービスについての追加の情報を伝える名前／値ペアを場所追跡デバイス２２０に提供する。ステップ２８８では、サービスディレクトリ２１０は、ＤＮＳ−ＳＤ応答（例えば、ｎａｅ０１の発見情報を含むＴＸＴレコード）を送信する。ステップ２８９では、場所追跡デバイス２２０は、受信されたＴＸＴレコード内の発見情報（例えば、ｎａｅ０１）を処理する。

概して、図１０のステップは、以下のように考えられ得る：ステップ２８０では、場所追跡デバイス２２０は、サービスディレクトリ２１０のアドレスを事前にプロビジョニングされる。ステップ２８１では、サービスディレクトリ２１０は、発見されることができる記録を事前にロードされる。ステップ２８２では、場所追跡デバイス２２０は、サービスディレクトリ２１０がいくつかのＮＡＥサービスについて把握しているかどうかをサービスディレクトリ２１０に尋ねる。ステップ２８３では、サービスディレクトリ２１０は、ポインタのリストを場所追跡デバイス２２０に提供する。サービスディレクトリ２１０が把握している各ＮＡＥサービスのためのポインタがあろう。各ポインタは、ＮＡＥサービスのインスタンスについてさらなる情報を見出すために進むことができる場所を場所追跡デバイス２２０に伝える。ステップ２８４では、場所追跡デバイス２２０は、ポインタを選ぶ。ステップ２８５では、ポインタは、サービス（例えば、場所追跡サービス２３０）のためのＳＲＶレコードを読み出すために使用されることができる。ＳＲＶレコードは、サービスについての詳細を提供する。具体的には、それは、サービスが到達されることができる場所を伝える。ステップ２８６では、ＳＲＶレコードは、場所追跡デバイス２２０に提供される。ステップ２８７では、場所追跡デバイス２２０は、サービスのためのＴＸＴレコードをフェッチする。ＴＸＴレコードは、サービスについてのさらなる詳細を与えるカスタマイズされた記録であることができる。ステップ２８８では、ＴＸＴレコードは、場所追跡デバイス２２０に送信される。ステップ２８９では、ＴＸＴレコードは、分析され、場所追跡デバイス２２０は、それがサービスを使用することを所望するかどうかを決定する。

図１０の前述のステップに関して要するに、場所追跡デバイス２２０が発見されたサービスと通信することに関心があると仮定すると、場所追跡デバイス２２０は、メッセージバスバックボーン２０２に参入することを決定することができる。場所追跡デバイス２２０のＯＭＢクライアント２２２は、発見されたサービスのＴＸＴファイルから、メッセージバスバックボーン２０２の一部（例えば、メッセージブローカ２０３）にアクセスするために使用され得る、ＩＰアドレス／ポート番号／プロトコルの組み合わせの組を取得することができる。ＴＸＴファイルは、発見されたサービスにアクセスするために、どのような待ち行列が使用され得るかを示すこともできる。

図７は、メッセージバスデータベースサービスの例示的説明図である。データベースサービス２４０は、データベースサービスを、メッセージブローカ２０３と接続される他のサービスに提供し得る。データベースサービス２４０は、図５に図示されるように、他のサービス２０４のうちの１つであり得る。図７は、データベースサービス２４０が、一般データベースインターフェース（ＧＤＩ）サービス２４２を備えて設計されることを示す。一般データベースインターフェース（ＧＤＩ）は、データベースアクセスおよびデータ管理の能力を提供する、複数のデータベースへの共通アプリケーションインターフェースである。データベースサービス２４０の一部（例えば、ＲＤＢＭＳ２４５およびＤＢＭＳ２４６）は、大部分が、本明細書で議論されるようなメッセージバスバックボーン２０２を認識していない。ＧＤＩサービス２４２は、表４に列挙されるＯＭＢ ＡＰＩとインターフェースをとるように設計される。図７では、例えば、ＯＭＢクライアント２４４は、ＡＭＱＰインターフェース２４３を利用する。しかしながら、ＯＭＢクライアント２４４は、代替として、ＯＭＢ ＡＰＩ ２４１が不変のままとなるような、異なるインターフェース（例えば、ＨＴＴＰ）に基づいて使用されることができる。

図９は、どのようにしてメッセージブローカ２０３に接続されたサービス間のエンドツーエンド通信が機能することができるかという例示的説明図である。各サービスは、そのローカルＯＭＢクライアントとインターフェースをとる。図９は、ＯＭＢクライアント２６５およびＯＭＢクライアント２６８が、それぞれ、トランスポートインターフェース２６６およびトランスポートインターフェース２６７を介して、ブローカとインターフェースをとることを示す。ＯＭＢクライアント２６５およびＯＭＢクライアント２６８は、異なるトランスポートインターフェースを使用し得る。例えば、ＯＭＢクライアント２６５が、ＡＭＱＰを介してメッセージブローカ２０３とインターフェースをとってもよい一方で、ＯＭＢクライアント２６８は、ＷｅｂＳｏｃｋｅｔｓを介してメッセージブローカ２０３とインターフェースをとる。各サービスは、他のサービス（例えば、ｘ−ｎｒａｒ）からメッセージを受信するために、メッセージブローカ２０３上でホストされる１つ以上の交換（例えば、交換２６９）を使用し得る。各サービスは、その交換をその待ち行列と結合し得る。結合は、サービスの待ち行列の名前（例えば、ｑ−ｎｓｅｃ）を交換に提供する。この名前は、メッセージをルーティングするために交換によって使用される。各サービスは、他のサービスからメッセージを受信するために、メッセージブローカ２０３上でホストされる１つ以上の待ち行列を使用する。各ＯＭＢクライアント（例えば、ＯＭＢクライアント２６５およびＯＭＢクライアント２６８）は、メッセージブローカ２０３への単一トランスポート接続しか要求しない。メッセージブローカ２０３は、通信チャネルを使用して、この単一トランスポート接続を経由して多重化されたメッセージの送信（生成）および受信（消費）をサポートする。

再度、図５を参照すると、メッセージバスバックボーン２０２に組み込まれる発見アーキテクチャは、メッセージバスバックボーン２０２に登録し、メッセージブローカ２０３を介して通信する前に、サービスが利用可能なサービスをブラウズすることを可能にする。実施例では、ＣｏＡＰを介して通信する軽量場所追跡センサ（例えば、場所追跡デバイス２２０）は、そのＧＰＳ座標をアップロードするために使用することができる場所追跡サービス（例えば、場所追跡サービス２３０）を発見することを所望するであろう。追跡センサが発見するであろう場所追跡サービスは、ＷｅｂＳｏｃｋｅｔｓを介して通信する。この使用事例は、図１１に示されるような例示的コールフローによって、かつ図５を参照して図示される。

本明細書でさらに詳細に議論されるが、図１１は、概して、メッセージバスへの登録およびサービス利用が後に続く、ＤＮＳ−ＳＤ発見について議論する。ステップ２９１では、場所追跡サービス２３０は、ＯＭＢ ＡＰＩを介して、そのサービスプロファイルをサービスディレクトリ２１０にパブリッシュし得る。ステップ２９２では、場所追跡デバイス２２０は、ＤＮＳ−ＳＤインターフェース２１１を使用してサービスディレクトリ２１０をブラウズする。ステップ２９３では、場所追跡デバイス２２０は、メッセージブローカ２０３と接続することを決定し、それは、場所追跡サービス２３０の存在によるものであり得る。ステップ２９４では、場所追跡デバイス２２０は、メッセージブローカ２０３を介して場所追跡サービス２３０とコンタクトする。

図１２は、サービスディレクトリへのサービス発見情報のパブリッシュのより詳細な実施例を図示する。要するに、図１１のステップ２９１を詳述する図１２を参照すると、メッセージブローカ２０３にすでに接続されている場所追跡サービス２３０は、それ（場所追跡サービス２３０）が他のサービスによって発見されることができるように、そのプロファイルをサービスディレクトリ２１０にパブリッシュする。場所追跡サービス２３０のサービスプロファイルがサービスディレクトリ２１０内に来ると、他のサービスによって発見され得る。場所追跡、課金、画像処理、およびテレメトリ等のサービスは、例えば、サービスディレクトリ２１０内でそれらのプロファイルをパブリッシュするために、このプロシージャを使用し得る。プロファイルは、ｏｍｂＳｅｒｖｉｃｅＩＤ、ｏｍｂＳｅｒｖｉｃｅＴｙｐｅ、およびブローカコンタクトアドレス等の情報を含み得る。場所追跡サービス２３０の例では、ｏｍｂＳｅｒｖｉｃｅＩＤは、メッセージブローカ２０３と接続される場所追跡サービス２３０を識別する識別子である。ｏｍｂＳｅｒｖｉｃｅＴｙｐｅは、サービスのタイプを識別する識別子である。この例では、これは、場所追跡サービス２３０が場所サービスを提供することを識別するであろう。ブローカコンタクトアドレスは、サービスがメッセージバスバックボーン２０２の１つ以上の部分にコンタクトして参入するために使用し得るＵＲＩ、ＩＰアドレス、もしくはポート番号であり得る。コンタクトアドレスの組があり得る。各アドレスは、異なるトランスポートプロトコルのために使用され得る。例えば、ＡＭＱＰ ＵＲＩ、ＷｅｂＳｏｃｋｅｔｓ ＵＲＩ、およびＭＱＴＴ ＵＲＩがあり得る。代替として、これらのＵＲＩは、サービスディレクトリ２１０によって提供され得る。

図１２をさらに参照すると、ブロック２９６は、典型的には、始動（例えば、初期化ステップ）時に起こる動作であり、その待ち行列にパブリッシュされるメッセージを受信するために、ＡＭＱＰブローカにサブスクライブするサービスディレクトリの例である。ステップ３０１では、ｏｍｂＣｏｎｆｉｇ（）ＡＰＩコールが、ＯＭＢクライアント２１４に送信される。このステップでは、サービスディレクトリ２１０は、その構成ファイルを用いて、そのＯＭＢクライアント２１４を構成している。ステップ３０２では、ｏｍｂＲｅｇｉｓｔｅｒ（）ＡＰＩコールが、そのＳｅｒｖｉｃｅＩＤをメッセージバスバックボーン２０２の１つ以上のコンポーネントに登録するために、サービスディレクトリ２１０から送信される。メッセージバスバックボーン２０２の１つ以上のコンポーネントは、サービスディレクトリ２１０のためのメッセージ待ち行列を作成し得る。ステップ３０３では、ｏｍｂＲｅｃｅｉｖｅ（）（ｓｄ＿ｃａｌｌｂａｃｋ＿ｆｃｎ）ＡＰＩコールを用いて、サービスディレクトリ２１０は、メッセージがメッセージブローカ２０３から受信されたときに何をすべきかをＯＭＢクライアント２１４に知らせる。ｓｄ＿ｃａｌｌｂａｃｋ＿ｆｃｎは、受信されたメッセージをハンドリングするために呼び出されるべき関数へのポインタである。

図１２のブロック２９７は、そのＯＭＢサービスプロファイルをサービスディレクトリにパブリッシュするサービスの例示的フローを図示する。ステップ３０４では、ｏｍｂＳｄＲｅｇｉｓｔｅｒ（）ＡＰＩコールを介して、場所追跡サービス２３０は、そのプロファイルがサービスディレクトリ２１０にロードされることを要求する。ステップ３０５では、場所追跡サービス２３０のＯＭＢクライアント２３１は、ｏｍｂＳｄＲｅｇｉｓｔｅｒ登録メッセージをサービスディレクトリ２１０のメッセージブローカ２０３にパブリッシュする。ステップ３０６では、メッセージブローカ２０３は、メッセージをサービスディレクトリ２１０のＯＭＢクライアント２１４に転送するためにコールバック関数を使用する。メッセージブローカ２０３は、コールバック関数で以前に構成されているが、このステップは示されていない。ステップ３０７では、ＯＭＢクライアント２１４は、新しいサービス登録をハンドリングする責任があるサービスディレクトリ関数を呼び出すために、ステップ３０３で提供されたｓｄ＿ｃａｌｌｂａｃｋ＿ｆｃｎポインタを使用する。ステップ３０７のメッセージは、以下のようなものであり得る：ｓｄ＿ｃａｌｌｂａｃｋ＿ｆｃｎ（ｏｍｂＭｓｇＩＤ＝１２３４，ｏｍｂＲｘＳｅｒｖｉｃｅＩＤ＝Ｓ１，ｏｍｂＭｓｇＴｙｐｅ＝ＳＤ Ｒｅｇ Ｒｅｑｕｅｓｔ，ｏｍｂＲｘＭｓｇＰａｙｌｏａｄ＝ＳＤ Ｐｒｏｆｉｌｅ）。ステップ３０８では、サービスディレクトリ２１０を使用して、プロファイルが記憶され、応答が作成され得る。ステップ３０９では、ｏｍｂＴｒａｎｓｍｉｔ（）ＡＰＩコールを使用して、サービスディレクトリ２１０は、その登録要求が成功したことをそれに知らせるメッセージを新しいサービスに返送する。ステップ３０９のメッセージは、以下のようなものであり得る：ｏｍｂＴｒａｎｓｍｉｔ（ｏｍｂＢｌｏｃｋｉｎｇ＝ＦＡＬＳＥ，ｏｍｂＴａｒｇｅｔ＝Ｓ１，ｏｍｂＭｓｇＩＤ＝１２３４，ｏｍｂＴｘＭｓｇＰａｙｌｏａｄ＝ＳＤ Ｒｅｇ Ｒｅｓｐｏｎｓｅ）。ステップ３１０では、ＯＭＢクライアント２１４は、ステップ３０９のメッセージをメッセージブローカ２０３にパブリッシュする。ステップ３１１では、メッセージブローカ２０３が、ステップ３０９のメッセージをＯＭＢクライアント２３１に転送する。ステップ３１２では、ＯＭＢクライアント２３１は、ステップ３０９のメッセージを場所追跡サービス２３０に転送する。

図１３は、ＤＮＳ−ＳＤベースの発見のより詳細な例を図示する。要するに、図１１のステップ２９２を詳述する図１３を参照すると、まだメッセージブローカ２０３と接続されていない場合がある場所追跡デバイス２２０は、メッセージブローカ２０３が利用可能な場所追跡サービスを有するかどうかをチェックするために、ＤＮＳ−ＳＤサーバ２１８にクエリを行い得る。ＤＮＳ−ＳＤサーバ２１８は、メッセージブローカ２０３のＡＭＱＰ ＵＲＩ、および場所追跡サービス２３０のＯＭＢＳｅｒｖｉｃｅＩｄ、またはメッセージバス２０３と接続された状態で見出されることができる場所追跡サービス２３０のｏｍｂＳｅｒｖｉｃｅＴｙｐｅを場所追跡デバイス２２０に提供し得る。随意に、場所追跡デバイス２２０が、そのＤＮＳ−ＳＤクエリを行うとき、場所追跡デバイス２２０は、どのようなタイプのトランスポートをそれがサポートするか（例えば、ＡＭＱＰ）を示し得、ＤＮＳ−ＳＤサーバ２１８は、どのようなＩＰアドレス、ポート番号、またはプロトコル情報がＴＸＴレコードに含まれるべきかを決定するために、この情報を使用し得る。場所追跡デバイス２２０が、それが使用することを所望するサービス（例えば、場所追跡サービス２３０）を選択すると、サービスにコンタクトしてそれを使用する方法を習得するために、場所追跡サービス２３０のＤＮＳ ＴＸＴファイルを使用するであろう。ｏｍｂＳｅｒｖｉｃｅＩＤは、メッセージブローカ２０３と接続される場所追跡サービス２３０を識別する識別子である。ｏｍｂＳｅｒｖｉｃｅＴｙｐｅは、サービスのタイプを識別する識別子である。この例では、これは、場所追跡サービス２３０が場所サービスを提供することを識別するであろう。ＴＸＴファイルは、ブローカコンタクトアドレスを含むであろう。ＢＲＯＫＥＲ＿ＩＰ、ＢＲＯＫＥＲ＿ＰＯＲＴ、およびＯＭＢ＿ＰＲＯＴＯＣＯＬ＿ＴＹＰＥは、コンタクトアドレスおよびメッセージングプロトコルを示す。ＴＸＴファイルは、発見を行う場所追跡デバイス２２０が、メッセージブローカ２０３にコンタクトするためにどのようなプロトコルを使用するであろうかを選定することができるように、複数のコンタクトアドレスおよびプロトコルを含み得る。場所追跡デバイス２２０は、ＤＮＳ ＴＸＴファイルから関連ＳＥＲＶＩＣＥ＿ＩＤを習得する。ＳＥＲＶＩＣＥ＿ＩＤは、メッセージバスバックボーン２０２の１つまたはその一部と接続するときに場所追跡サービス２３０にコンタクトするために、場所追跡デバイス２２０によって使用され得る。

図１３をさらに参照すると、ＯＭＢクライアント２２２とＤＮＳ−ＳＤサーバ２１０との間の相互作用は、メッセージブローカ２０３を経由して起こらず、それは、別個のＤＮＳ−ＳＤインターフェース２１１を経由する。代替として、ＯＭＢクライアント２２２がＤＮＳ−ＳＤインターフェースをサポートしなかった場合、場所追跡デバイス２２０がＤＮＳ−ＳＤをサポートし、ＤＮＳ−ＳＤサーバ２１０にクエリを行い得る。ＤＮＳ−ＳＤ発見に関する詳細は、以下の通りである。ステップ３２０では、場所追跡デバイス２２０は、特定のタイプのサービスに対してサービスディレクトリ２１０をブラウズするために、ＯＭＢクライアント２２２がそのＤＮＳ−ＳＤインターフェース２１１を使用することを要求し得る。本明細書で定義されるｏｍｂＳｄＤｉｓｃｏｖｅｒ（）ＡＰＩコールは、ＯＭＢクライアント２２２に要求を行うために使用され得る。ステップ３２０の代替として、ＯＭＢクライアント２２２は、複数のサーバ上で検索を行うことができるように、複数のＤＮＳ−ＳＤサーバのコンタクト情報をプロビジョニングされ得る。

ステップ３２１では、本明細書でさらに詳細に議論されるように、ＯＭＢクライアント２２２は、ＤＮＳ−ＳＤサーバ２１８にＰＴＲレコード要求を行う。ステップ３２２では、ＤＮＳ−ＳＤサーバ２１８は、要求されたＳｅｒｖｉｃｅＴｙｐｅに一致する０−Ｎ ｓｅｒｖｉｃｅＩｄで応答する。ステップ３２３では、ＯＭＢクライアント２２２は、ステップ３２２で提供されたリスト内の第１のサービスに関連付けられるＴＸＴレコードを要求する。ステップ３２４では、ＤＮＳ−ＳＤサーバ２１８は、第１のサービスのためのＴＸＴレコードで応答する。ステップ３２５では、ＯＭＢクライアント２２２は、第１のサービスのためのＴＸＴレコードを記憶する。ステップ３２６では、ＯＭＢクライアント２２２は、ステップ３２２で提供されたリスト内のＮ番目のサービスに関連付けられるＴＸＴレコードを要求するであろう。ステップ３２７では、ＤＮＳ−ＳＤサーバ２１８は、Ｎ番目のサービスのためのＴＸＴレコードで応答する。ステップ３２８では、ＯＭＢクライアント２２２は、Ｎ番目のサービスのためのＴＸＴレコードを記憶する。ステップ３２９では、ＯＭＢクライアント２２２は、本明細書で議論される、ｏｍｂＳｄＤｉｓｃｏｖｅｒ（）ＡＰＩに応答することによって、発見されたサービスのリストを場所追跡デバイス２２０に提供する。

図１４は、メッセージブローカ２０３またはメッセージバスバックボーン２０２の他の部分と接続するためのより詳細な例示的方法フローを図示する。要するに、図１１のステップ２９３を詳述する図１４を参照すると、場所追跡デバイス２２０は、メッセージバスバックボーン２０２の１つ以上のコンポーネント（例えば、メッセージブローカ２０３）に参入することを決定し得る。場所追跡デバイス２２０は、メッセージブローカ２０３との接続（例えば、ＡＭＱＰ接続）を開くために、前のステップで発見されたブローカコンタクトアドレスを使用し得る。メッセージブローカ２０３との接続に関する詳細は、以下の通りである。ステップ３３０では、場所追跡デバイス２２０は、ＯＭＢクライアント２２２がメッセージブローカ２０３と接続することを要求するために、ｏｍｂＲｅｇｉｓｔｅｒ（）ＡＰＩを使用する。ステップ３３１では、ＯＭＢクライアント２２２がＡＭＱＰトランスポートインターフェースを伴って設計されると仮定して、ＯＭＢクライアント２２２は、メッセージブローカ２０３にコンタクトし、接続が開かれることを要求するために、ＡＭＱＰ ＵＲＩを使用する。ＡＭＱＰ ＵＲＩは、図１３のステップ２９２に関して説明される発見プロセス中に取得されているであろう。ＯＭＢクライアント２２２は、他のトランスポートインターフェース（例えば、ＣｏＡＰ等）を使用するように設計され得る。この例は、下層トランスポートがＡＭＱＰである事例を対象とする。

ステップ３３２では、メッセージブローカ２０３に対するＡＭＱＰインターフェースは、ステップ３３１の要求に応答する。ステップ３３３では、セキュリティが、ＡＭＱＰ接続上で確立される（例えば、セキュリティチャレンジ）。ＯＭＢクライアント２２２は、ＤＮＳ−ＳＤルックアップ中に取得されたＴＸＴレコードからの接続パラメータを使用する。ステップ３３４では、セキュリティが、ＡＭＱＰ接続上で確立される（例えば、セキュリティ応答）。ステップ３３５では、ＡＭＱＰ接続が構成される（例えば、提案された最大チャネル、提案された最大フレームサイズ、所望のハートビート遅延等）。ＯＭＢクライアント２２２は、ＤＮＳ−ＳＤルックアップ中に取得されたＴＸＴレコードからの接続パラメータを使用する。ステップ３３６では、ＡＭＱＰ接続が構成される（例えば、ネゴシエートされた最大チャネル、ネゴシエートされた最大フレームサイズ、ネゴシエートされたハートビート遅延等）。ステップ３３７では、メッセージブローカ２０３のＡＭＱＰは、接続が確立されていることを肯定応答する（例えば、プロトコルバージョン、サーバプロパティ、利用可能なセキュリティ等）。ステップ３３８では、ＯＭＢクライアント２２２のＡＭＱＰは、接続が確立されていることを肯定応答する（例えば、選択されたセキュリティ、クライアントプロパティ等）。ステップ３３９では、ＯＭＢクライアント２２２は、ステップ３３１のｏｍｂＲｅｇｉｓｔｅｒ（）要求に応答する。応答は、登録要求が成功した、拒否された、またはエラーを引き起こしたかどうかというインジケーションを含み得る。

図１５は、メッセージバスバックボーン２０２の１つ以上のコンポーネント（例えば、メッセージブローカ２０３）を使用して、発見されたサービスと通信するための例示的方法フローである。要するに、場所追跡デバイス２２０は、メッセージを場所追跡サービス２３０に送信するために、発見されたｏｍｂＳｅｒｖｉｃｅＩＤを使用する。発見されたＯＭＢＳｅｒｖｉｃｅＩＤまたはｏｍｂＳｅｒｖｉｃｅＴｙｐｅが使用されることに留意されたい。ステップ３４１では、場所追跡デバイス２２０は、前に発見された場所追跡サービス２３０のために意図されるメッセージ（例えば、ｏｍｂＴｒａｎｓｍｉｔ（）ＡＰＩコール）を送信する。ステップ３４１のメッセージは、以下のようなものであり得る：ｏｍｂＴｒａｎｓｍｉｔ（ｏｍｂＢｌｏｃｋｉｎｇ＝Ｆａｌｓｅ，ｏｍｂＴａｒｇｅｔ＝Ｓ２，ｏｍｂＴｏｋｅｎ＝ＡＢＣ，ｏｍｂＴｘＭｓｇＰａｙｌｏａｄ ｏｍｂＣａｌｌｂａｃｋＦｃｎ＝Ｓ１＿ｃａｌｌｂａｃｋ＿ｆｃｎ）。前に発見されたＯＭＢＳｅｒｖｉｃｅＩＤは、標的場所追跡サービス２３０を識別するために使用され得る。図１５では、場所追跡サービス２３０が、Ｓ２（サービス２）と呼ばれる一方で、場所追跡デバイス２２０は、Ｓ１（サービス１）と呼ばれる。ステップ３４２では、ＯＭＢクライアント２２２は、ステップ３４１のメッセージをメッセージブローカ２０３にパブリッシュする。ステップ３４２のメッセージは、以下のようなものであり得る：ｐｕｂｌｉｓｈ（ｅｘｃｈａｎｇｅ＝’ｘ−ｓ２’，ｒｏｕｔｉｎｇ ｋｅｙ＝’Ｓ２’，ＯＭＢ Ｍｅｓｓａｇｅ）。ステップ３４３では、メッセージブローカ２０３は、ステップ３４１のメッセージをＯＭＢクライアント２３１に転送する。ステップ３４４では、ＯＭＢクライアント２２２は、メッセージを場所追跡サービス２３０に転送する。ステップ３４４のメッセージは、以下のようなものであり得る：ｓｄ＿ｃａｌｌｂａｃｋ＿ｆｃｎ（ｏｍｂＭｓｇＩＤ＝１２３４，ｏｍｂＴｏｋｅｎ＝ＡＢＣ，ｏｍｂＲｘＳｅｒｖｉｃｅＩＤ＝Ｓ１，ｏｍｂＭｓｇＴｙｐｅ＝Ｔｘ Ｒｅｑｕｅｓｔ，ｏｍｂＲｘＭｓｇＰａｙｌｏａｄ＝Ｔｘ ｐａｙｌｏａｄ）。ステップ３４５では、場所追跡サービス２３０は、ステップ３４１のメッセージを処理する。ステップ３４６では、場所追跡サービス２３０は、ｏｍｂＴｒａｎｓｍｉｔ ＡＰＩを使用することによって要求に応答する。場所追跡サービス２３０は、ステップ３４４でｓｄ＿ｃａｌｌｂａｃｋ＿ｆｃｎによって提供された同一のサービスＩＤを使用することによって、それが応答しているサービスを識別し得る。ステップ３４６のメッセージは、以下のようなものであり得る：ｏｍｂＴｒａｎｓｍｉｔ（ｏｍｂＢｌｏｃｋｉｎｇ＝ＦＡＬＳＥ，ｏｍｂＴａｒｇｅｔ＝Ｓ１，ｏｍｂＭｓｇＩＤ＝１２３４，ｏｍｂＴｏｋｅｎ＝ＡＢＣ，ｏｍｂＴｘＭｓｇＰａｙｌｏａｄ＝Ｔｘ Ｒｅｓｐｏｎｓｅ）。ステップ３４７では、ＯＭＢクライアント２３１は、メッセージをメッセージブローカ２０３にパブリッシュする。ステップ３４７のメッセージは、以下のようなものであり得る：ｐｕｂｌｉｓｈ（ｅｘｃｈａｎｇｅ＝’ｘ−ｓ１’，ｒｏｕｔｉｎｇ ｋｅｙ＝’Ｓ１’，ＯＭＢ Ｍｅｓｓａｇｅ）。ステップ３４８では、メッセージブローカ２０３は、ステップ３４６のメッセージをＯＭＢクライアント２２２に転送する。ステップ３４９では、ＯＭＢクライアント２２２は、ステップ３４６のメッセージを、要求を処理する場所追跡デバイス２２０に転送する。ステップ３４９のメッセージは、以下のようなものであり得る：ｓ１＿ｃａｌｌｂａｃｋ＿ｆｃｎ（ｏｍｂＲｓｐＣｏｄｅ，ｏｍｂＲｘＭｓｇＴｙｐｅ＝Ｔｘ＿Ｒｓｐ，ｏｍｂＴｏｋｅｎ＝ＡＢＣ，ｏｍｂＲｘＭｓｇＰａｙｌｏａｄ）。

図１６は、本明細書で議論されるＯＭＢアーキテクチャを使用して、どのようにしてｏｎｅＭ２Ｍサービス（ＣＳＦ）またはサービスコンポーネント（例えば、サービスのグループ）が展開され得るかという例示的実装を図示する。各サービスが独自のＯＭＢクライアント（ＣＳＦ１およびＣＳＦ６）を伴って展開されることができることに留意されたい。複数のサービスがＯＭＢクライアント（ＣＳＦ２およびＣＳＦ３）を共有し得ることに留意されたい。Ｍｃｃ、Ｍｃａ、およびＭｃｎ参照点は、メッセージバスブローカをトラバースしないこともある。それらは、それぞれ、遠隔サービス、アプリケーション、または外部ネットワークに到達するために、インターネットに直接ルーティングされ得る。Ｍｓｃ参照点は、ＯＭＢにマップまたは結合され得る（どのようにしてＭｓｃ参照点がサービスを接続するかを実証する別の図については、図４を参照されたい）。ＣＳＦおよびＯＭＢクライアントは、同一のネットワークサーバ上または別個の遠隔ネットワークサーバ上に展開され得ることに留意されたい。

ここでは、メッセージブローカ２０３とのサービスのトランスポートに依存しない接続を可能にすることを補助し得るＯＭＢ ＡＰＩ（例えば、ＯＭＢ ＡＰＩ ２２５、ＯＭＢ ＡＰＩ２１４等）に関する詳細が議論される。メッセージブローカ２０３と接続されると、ＯＭＢ ＡＰＩ ２２５は、メッセージブローカ２０３と接続された他のサービスとメッセージを交換するために使用されることができる。メッセージブローカ２０３は、ブローカとしての役割を果たすので、クライアント間でメッセージをパスする。以下の特徴が、ＯＭＢ ＡＰＩによってサポートされ得る：１）独立し、下層トランスポートプロトコルに依存しない、２）独立し、上層サービスプロトコルに依存しない、３）ブロッキングおよび非ブロッキング機能性をサポートする、および、４）オブジェクト指向原理に基づく。記述されるように、ＯＭＢ ＡＰＩ ２２５は、独立し、下層ＯＭＢトランスポートプロトコルに依存しない（例えば、メッセージパッシング、ＡＭＱＰ、ＸＭＰＰ、ＭＱＴＴ、Ｗｅｂ Ｓｏｃｋｅｔｓ等）。下層トランスポートは、ＯＭＢクライアント２２２によって隠され得る。ＯＭＢ ＡＰＩ ２２５は、独立し、メッセージブローカ２０３を使用する上層サービスプロトコルに依存しない。ＯＭＢ ＡＰＩ ２２５を使用する各上層サービス（例えば、ｏｎｅＭ２Ｍサービス、ＥＴＳＩ Ｍ２Ｍサービス等）は、ＯＭＢ ＡＰＩ ２２５に結合されることが予期される。したがって、ＯＭＢ ＡＰＩは、サービスが使用するペイロードフォーマットから独立している。例えば、サービスは、ＸＭＬ、ＪＳＯＮ、カスタムフォーマット等を使用することができる。

ＯＭＢ ＡＰＩ ２２５は、ブロッキングおよび非ブロッキング機能性をサポートする。非ブロッキング機能性をサポートするために、ＯＭＢ ＡＰＩ（例えば、ＯＭＢ ＡＰＩ ２２５）は、コールバック関数がＯＭＢクライアント２２２に提供されることを可能にする。メッセージは、メッセージブローカ２０３上に配置されることができ、コールバック関数は、応答が受信されるときにＯＭＢクライアント２２２によって呼び出されることができる。ＯＭＢ ＡＰＩ ２２５の設計は、オブジェクト指向原理に基づき、ライブラリとして設計される。

ＯＭＢ ＡＰＩは、異なるタイプの機能性をサポートする。第１の例では、サービス（例えば、場所追跡デバイス２２）は、対応するＯＭＢサービス構成設定に基づいてＯＭＢクライアント２２２を構成することができる（表１参照）。第２の例では、場所追跡サービス２３０は、ＯＭＢクライアント２２５とメッセージブローカ２０３との間の接続または登録を開始し得る。これは、対応するＯＭＢサービス構成設定に基づいてメッセージブローカ２０３を構成すること（例えば、交換、待ち行列、結合等の必要なメッセージブローカ構築物を作成／構成する）をもたらす。第３の例では、ＯＭＢサービス（例えば、場所追跡デバイス２２０）は、サービスディレクトリ２１０を介して、メッセージブローカ２０３に接続された他の利用可能なＯＭＢサービス（例えば、場所追跡サービス２３０）を発見し得る。第４の例では、ＯＭＢサービスは、データベースサービス２４０に記憶された情報を作成し／読み出し／更新し／削除し得る。第５の例では、ＯＭＢサービスは、メッセージブローカ２０３を経由してメッセージを送信または受信し得る。第６の例では、ＯＭＢサービスは、それ自体についての管理またはデバッグ情報を管理サービス２５０に提供し得る。第７の例では、管理サービスは、ＯＭＢサービスを管理するために使用され得る。第８の例では、ＯＭＢサービスは、ＯＭＢサービスディレクトリにサブスクライブし、通知基準（例えば、特定のタイプのサービスがメッセージブローカ２０３と接続する場合／とき）を規定し得る。第９の例では、ＯＭＢサービスは、ＯＭＢクライアント（例えば、ＯＭＢクライアント２２２）とメッセージブローカ２０３との間の切断または登録解除を開始し得る。

メッセージブローカ２０３またはメッセージバスバックボーン２０２の別の部分と接続するサービスは、ＯＭＢＳｅｒｖｉｃｅＩＤを使用し得る。ＯＭＢＳｅｒｖｉｃｅＩＤは、メッセージバスバックボーン２０２の１つ以上のコンポーネントによって割り当てられる識別子である。ＯＭＢＳｅｒｖｉｃｅＩＤは、バス上の各サービスを識別するために使用される。ＯＭＢＳｅｒｖｉｃｅＩＤは、サービスの中にプロビジョニングされ得るか、またはメッセージバスバックボーン２０２への登録時に割り当てられ得る。サービスは、メッセージバスバックボーン２０２と接続し、いかなるサービスも他のサービスに提供しないこともある。しかしながら、そのようなサービスは、それがバス上で通信することができるように、依然としてＯＭＢＳｅｒｖｉｃｅＩＤを割り当てられるであろう。サービスを提供しない「サービス」の例は、単純に、他のサービスから情報を収集し、アラームをトリガするアラームサービス（例えば、サイレンデバイス）であり得る。

サービスは、ｏｍｂＳｅｒｖｉｃｅＴｙｐｅも割り当てられ得る。ｏｍｂＳｅｒｖｉｃｅＴｙｐｅは、サービスのタイプを識別する。例えば、ｏｍｂＳｅｒｖｉｃｅＴｙｐｅは、関連付けられたサービスがセンサであること、または関連付けられたサービスが画像処理用であることを示し得る。ｏｍｂＳｅｒｖｉｃｅＴｙｐｅは、サービスの中にプロビジョニングされ得るか、またはメッセージバスバックボーン２０２の１つ以上のコンポーネントへの登録時に割り当てられ得る。ＯＭＢＳｅｒｖｉｃｅＩＤおよびｏｍｂＳｅｒｖｉｃｅＴｙｐｅは、他のサービスを発見してアドレスするために、サービスによって使用される。例えば、ＯＭＢＳｅｒｖｉｃｅＩＤは、メッセージをサービスの特定のインスタンスに送信するために使用されることができ、ｏｍｂＳｅｒｖｉｃｅＴｙｐｅは、特定のサービスタイプに関連する全てのメッセージにサブスクライブするために使用されることができる。例示的コールフローが、本明細書で議論される。ＯＭＢクライアントは、ｏｍｂＧｒｏｕｐＩｄ等の追加の随意の識別子を割り当てられ得る。複数のｏｍｂＧｒｏｕｐＩｄが、各ＯＭＢクライアントに割り当てられ得る。ｏｍｂＧｒｏｕｐＩｄは、所有権、コスト、タイプ、アクセス権等に基づいて、クライアントをグループ化するために使用され得る。

ＯＭＢ ＡＰＩのさらなる説明が、本明細書で議論される。以下は、ＯＭＢ ＡＰＩ ２２５等によってサポートされる関数コールがグループ化され得るカテゴリである：１）メッセージブローカを経由して通信するために使用される一般ＯＭＢ ＡＰＩ関数（表２に示される）、２）ＯＭＢサービスディレクトリＡＰＩ関数（表３に示される）、３）ＯＭＢデータベースＡＰＩ関数（表４に示される）、および４）ＯＭＢ管理コンソールＡＰＩ関数。

表５は、ＯＭＢ ＡＰＩによってサポートされる共通のパラメータの組を列挙する。これらの共通パラメータは、ＯＭＢ ＡＰＩコールの多くの中で出現し、ここで説明される。

ｏｍｂＣｏｎｆｉｇ（）関数は、サービスおよびメッセージブローカに特定の情報でＯＭＢクライアントを構成するために、サービスによって呼び出される。さらなる詳細が、表６に示されている。

表７は、可能なｏｍｂＲｅｇｉｓｔｅｒ（）入出力パラメータを列挙する。ｏｍｂＲｅｇｉｓｔｅｒ（）は、メッセージバスバックボーンに登録し、ＯＭＢ交換を作成するためにＯＭＢサービスによって呼び出される。交換は、ＯＭＢの一部である。交換は、サービスからメッセージを受理し、それを待ち行列にルーティングする。待ち行列に入ると、メッセージは、１つ以上のサービスに送信されるであろう。基本的に、この関数は、ＯＭＢへの接続を作成するために使用される。「接続」は、「ＯＭＢ交換」である。

表８は、可能なｏｍｂＤｅｒｅｇｉｓｔｅｒ（）入出力パラメータを列挙する。ｏｍｂＤｅｒｅｇｉｓｔｅｒ（）関数は、メッセージブローカと登録解除するために、ＯＭＢサービスによって呼び出される。

ｏｍｂＲｅｃｅｉｖｅ（）関数は、ＯＭＢクライアントから未承諾メッセージを受信するために、ＯＭＢサービスによって呼び出される。この受信は、ブロッキングまたは非ブロッキング様式のいずれかで行われることができる。加えて、受信は、１つ以上の定義されたＯＭＢメッセージタイプに対して行われることができる。

ＯＭＢクライアントがメッセージブローカからＯＭＢメッセージを受信するとき、それは、メッセージが承諾または未承諾であるかどうかを決定するようにチェックするであろう。承諾メッセージは、ＯＭＢクライアントからの以前に伝送されたＯＭＢメッセージと一致するＯＭＢメッセージＩＤを有する（例えば、このメッセージは、前の要求への応答である）。未承諾メッセージは、以前に伝送されたＯＭＢメッセージと一致しないＯＭＢメッセージである。

表９を参照すると、受信されるＯＭＢメッセージのタイプに応じて、ＯＭＢクライアントは、それをＯＭＢサービスに転送する前に、ＯＭＢメッセージペイロードをデコードすることも、デコードしないこともある。例えば、ＯＭＢクライアントは、ＯＭＢサービスディレクトリから発信するＯＭＢメッセージのＯＭＢメッセージペイロードをデコードする。一方で、ＯＭＢクライアントは、バックボーンサービスではない、ＯＭＢクライアントが認識／知識を有していないＯＭＢサービス（例えば、ｏｎｅＭ２ＭサービスまたはＥＴＳＩ Ｍ２Ｍサービス等）から発信するＯＭＢメッセージのＯＭＢメッセージペイロードをデコードしない。

表１０は、可能なｏｍｂＴｒａｎｓｍｉｔ（）入出力パラメータを列挙する。ｏｍｂＴｒａｎｓｍｉｔ（）関数は、メッセージを他のＯＭＢサービスに伝送するために、ＯＭＢサービスによって呼び出される。この伝送は、ブロッキングまたは非ブロッキング様式のいずれかで行われることができる。

表１１は、可能なｏｍｂＳｄＲｅｇｉｓｔｅｒ（）入出力パラメータを列挙する。ｏｍｂＳｄＲｅｇｉｓｔｅｒ（）関数は、（ＤＮＳ−ＳＤインターフェースではなくＯＭＢを介して）ＯＭＢサービスディレクトリ内にサービスプロファイルを作成するために、ＯＭＢサービスによって呼び出される。登録は、存続期間が満了する前にｏｍｂＳｄＵｐｄａｔｅ（）を介して更新される必要があり得るように、それに関連付けられる存続期間を有し得る。そうでなければ、登録は、ＯＭＢサービスディレクトリによって自動的に削除され得る。構成ファイルおよび／またはＤＮＳ ＴＸＴレコードからの情報は、ＯＭＢサービスディレクトリプロファイルを作成するために使用され得る。

表１２は、可能なｏｍｂＳｄＤｅｒｅｇｉｓｔｅｒ（）入出力パラメータを列挙する。ｏｍｂＳｄＤｅｒｅｇｉｓｔｅｒ（）関数は、ＯＭＢサービスディレクトリからサービスプロファイルを登録解除するために、ＯＭＢサービスによって呼び出される。

表１３は、可能なｏｍｂＳｄＵｐｄａｔｅ（）入出力パラメータを列挙する。ｏｍｂＳｄＵｐｄａｔｅ（）関数は、そのサービスディレクトリプロファイルを更新するために、ＯＭＢサービスによって呼び出される。この関数は、ＯＭＢサービスがそのＯＭＢサービスディレクトリプロファイルを認識し、サービスディレクトリ内で独自のプロファイルを動的に更新／作成するときに使用される。

表１４は、可能なｏｍｂＳｄＤｉｓｃｏｖｅｒ（）入出力パラメータを列挙する。ｏｍｂＳｄＤｉｓｃｏｖｅｒ（）関数は、特定のクエリに一致するＯＭＢに接続された利用可能なＯＭＢサービスを発見して読み出すために、ＯＭＢサービスディレクトリにクエリを行うためにＯＭＢサービスによって呼び出される。

このＡＰＩコールは、（利用可能であるときに）下層ＤＮＳベースのサービスディレクトリを利用するであろう。そうでなければ、それは、発見のためにＯＭＢベースのサービスディレクトリを利用するであろう。

表１５は、可能なｏｍｂＳｄＳｕｂｓｃｒｉｂｅ（）入出力パラメータを列挙する。ｏｍｂＳｄＳｕｂｓｃｒｉｂｅ（）関数は、ＯＭＢサービスプロファイルが作成、更新、または削除されるとき等に、状態変化の通知を受信するために、ＯＭＢサービスディレクトリにサブスクライブするためにＯＭＢサービスによって呼び出される。

表１６は、可能なｏｍｂＤｂＲｅｇｉｓｔｅｒ（）入出力パラメータを列挙する。ｏｍｂＤｂＲｅｇｉｓｔｅｒ（）関数は、ＯＭＢデータベースに登録するために、ＯＭＢサービスによって呼び出される。

表１７は、可能なｏｍｂＤｂＤｅｒｅｇｉｓｔｅｒ（）入出力パラメータを列挙する。ｏｍｂＤｂＤｅｒｅｇｉｓｔｅｒ（）関数は、ＯＭＢデータベースから登録解除するために、ＯＭＢサービスによって呼び出される。

表１８は、可能なｏｍｂＤｂＣｒｅａｔｅＲｅｓｏｕｒｃｅ（）入出力パラメータを列挙する。ｏｍｂＤｂＣｒｅａｔｅＲｅｓｏｕｒｃｅ（）関数は、ＯＭＢデータベース内でリソースを作成するために、ＯＭＢサービスによって呼び出される。

表１９は、可能なｏｍｂＤｂＲｅｔｒｉｅｖｅＲｅｓｏｕｒｃｅ（）入出力パラメータを列挙する。ｏｍｂＤｂＲｅｔｒｉｅｖｅＲｅｓｏｕｒｃｅ（）関数は、ＯＭＢデータベースからリソースを読み出すために、ＯＭＢサービスによって呼び出される。

表２０は、可能なｏｍｂＤｂＵｐｄａｔｅＲｅｓｏｕｒｃｅ（）入出力パラメータを列挙する。ｏｍｂＤｂＵｐｄａｔｅＲｅｓｏｕｒｃｅ（）関数は、ＯＭＢデータベース内のリソースを更新するために、ＯＭＢサービスによって呼び出される。

表２１は、可能なｏｍｂＤｂＤｅｌｅｔｅＲｅｓｏｕｒｃｅ（）入出力パラメータを列挙する。ｏｍｂＤｂＤｅｌｅｔｅＲｅｓｏｕｒｃｅ（）関数は、ＯＭＢデータベース内のリソースを削除するために、ＯＭＢサービスによって呼び出される。

表２２は、可能なｏｍｂＤｂＦｉｎｄＡｌｌＳｕｂｓｃｒｉｐｔｉｏｎｓ（）入出力パラメータを列挙する。ｏｍｂＤｂＦｉｎｄＡｌｌＳｕｂｓｃｒｉｐｔｉｏｎｓ（）関数は、データベース内の標的リソースの下の全てのサブスクライブリソースを再帰的に見出すために、ＯＭＢサービスによって呼び出される。

表２３は、可能なｏｍｂＤｂＦｉｎｄＡｌｌＣｈｉｌｄＲｅｓｏｕｒｃｅｓ（）入出力パラメータを列挙する。ｏｍｂＤｂＦｉｎｄＡｌｌＣｈｉｌｄＲｅｓｏｕｒｃｅｓ（）関数は、ＯＭＢデータベース内で１つのレベルのみに対して親リソースの下の全ての子リソースを見出すために、ＯＭＢサービスによって呼び出される。

表２４は、可能なｏｍｂＤｂＦｉｎｄＡｌｌＣｈｉｌｄＲｅｓｏｕｒｃｅｓＲｅｃｕｒｓｉｖｅｌｙ（）入出力パラメータを列挙する。ｏｍｂＤｂＦｉｎｄＡｌｌＣｈｉｌｄＲｅｓｏｕｒｃｅｓＲｅｃｕｒｓｉｖｅｌｙ（）関数は、ＯＭＢデータベース内で再帰的に所与の標的リソースの下の全ての子リソースを見出すために、ＯＭＢサービスによって呼び出される。

表２５は、可能なｏｍｂＤｂＩｓＲｅｓｏｕｒｃｅＰｒｅｓｅｎｔ（）入出力パラメータを列挙する。ｏｍｂＤｂＩｓＲｅｓｏｕｒｃｅＰｒｅｓｅｎｔ（）関数は、規定検索文字列に一致するリソースについてＯＭＢデータベースを再帰的に検索するように、ＯＭＢサービスによって呼び出される。

Ａｄｖａｎｃｅｄ Ｍｅｓｓａｇｅ Ｑｕｅｕｉｎｇ Ｐｒｏｔｏｃｏｌ（ＡＭＱＰ）およびＭｅｓｓａｇｅ Ｑｕｅｕｉｎｇ Ｔｅｌｅｍｅｔｒｙ Ｔｒａｎｓｐｏｒｔ（ＭＱＴＴ）等の従来のメッセージングバスプロトコルは、どのようなサービスがメッセージバス上で利用可能であるかを動的に発見するための組み込みのサポートを有していない。したがって、メッセージバスに接続されるサービスは、どのような他のメッセージがメッセージバス上にあるかを認識しない場合がある。これは、メッセージバスのサービスの過小利用をもたらし得る。例えば、ホームオートメーションサービスプロバイダは、地元の気象状態についての情報を提供するサービスに接続することが可能である場合、家庭暖房および冷房システムをより効率的に管理することが可能であり得る。ＡＭＱＰおよびＭＱＴＴは、ホームオートメーションプロバイダが気象サービスを動的に発見して使用する手段を提供しない。

サービスがアクセスすることを所望する別のサービスを発見する場合、２つのサービスの下層トランスポートプロトコルの適合性がないであろう可能性がある。例えば、低コストＩｏＴセンサ上でホストされるサービスが、ＣｏＡＰ等の軽量ＵＤＰベースのプロトコルを介してメッセージングシステムに接続し得る一方で、サーバ上でホストされるデータマイニングサービスは、ＷｅｂＳｏｃｋｅｔｓ等のＴＣＰベースのプロトコルを介してメッセージングシステムに接続し得る。メッセージブローカと接続するためにサービスによって使用される、本明細書で議論されるＡＰＩまたはプロトコルは、ピアサービスによって使用されるトランスポートプロトコルに非依存であり得る。新しいプロトコルが、ＯＭＢクライアント２６５のトランスポートインターフェースを更新することによってサポートされることができる。ＯＭＢクライアントＡＰＩは、必ずしも変化せず、トランスポートインターフェースが、変化するであろう。メッセージブローカもまた、新しいトランスポートインターフェースをサポートするために更新されるであろう。

サービスは、動的にメッセージバスに関連付けおよび関連付け解除し得る。サービスがメッセージバスに関連付けるとき、他のサービスが通知され得る。例えば、暖房および冷房システムサービスは、気象感知サービスが利用可能であるときを把握することを所望し得る。サービスがメッセージバスに関連付け解除するとき、他のサービスが通知され得る。例えば、同一の暖房および冷房システムサービスは、新しい気象感知サービスをみつけ得るように、気象感知サービスが関連付け解除するときを把握することを所望し得る。従来、新しいメンバがメッセージバスに関連付けおよび関連付け解除するとき、メッセージバスに関連付けられる全てのサービスが通知されるであろうことを当然のことと思わないであろう。本明細書で議論されるようなメッセージバスプロトコルまたはインフラストラクチャは、サービスがどのような他のサービスに関心があるかを示し、これらの他のサービスがメッセージバスに関連付けおよび関連付け解除するとき、メッセージバスがサービスに知らせることを要求する手段を提供する。

本開示の全体を通して、メッセージバスバックボーンと接続し、どのようなサービスがメッセージバスバックボーンの１つ以上のコンポーネント（例えば、メッセージブローカ２０３）を介して利用可能である（例えば、それに登録または接続される）かをブラウズするためにサービスディレクトリを使用するサービスが参照される。「デバイス」という用語は、サービスと同義的に使用されることができる。サービスは、多くの場合、あるタイプの計算または記憶を行う論理エンティティを指す。デバイスは、多くの場合、物理的であるものを指し、サービスより劣った機能性を有し得る。例えば、サイレンデバイスは、単純に、他のサービスから感知された情報を収集し、サイレンを鳴らすかどうかについて決定を行い得る。サービスおよびデバイスは両方とも、本明細書で開示されるようなメッセージバスバックボーンと接続し、どのようなサービスがメッセージバスバックボーンの１つ以上のコンポーネントを介して利用可能であるかをブラウズするためにサービスディレクトリを使用することができる。本明細書で議論されるリソースは、ネットワーク（例えば、ウェブ）を介して識別され、名前を付けられ、（典型的には、ＵＲＩを使用して）アドレスされることができるエンティティである。

ｏｎｅＭ２ＭおよびＥＴＳＩ Ｍ２Ｍアーキテクチャが、本明細書で背景として説明され、本明細書に説明される主題を例証するために使用され得るが、本明細書に説明される主題の実装は、本開示の範囲内にとどまりながら変動し得ることを理解されたい。当業者はまた、開示される主題が、本明細書で議論されるｏｎｅＭ２ＭおよびＥＴＳＩ Ｍ２Ｍアーキテクチャを使用する実装に限定されず、むしろ、他のアーキテクチャおよびシステムで実装され得ることを認識するであろう。

図１７Ａは、１つ以上の開示される概念が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構築ブロックを提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントならびにＩｏＴ／ＷｏＴサービス層等であり得る。

図１７Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、Ｅｔｈｅｒｎｅｔ（登録商標）、Ｆｉｂｅｒ、ＩＳＤＮ、ＰＬＣ等）または無線ネットワーク（例えば、ＷＬＡＮ、セルラー等）、もしくは異種ネットワークのネットワークであり得る。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージング、ブロードキャスト等のコンテンツを複数のユーザに提供する複数のアクセスネットワークから成り得る。例えば、通信ネットワーク１２は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）等の１つ以上のチャネルアクセス方法を採用し得る。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワーク等の他のネットワークを備え得る。

図１７Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインと、フィールドドメインとを含み得る。インフラストラクチャドメインは、エンドツーエンドＭ２Ｍ展開のネットワーク側を指し、フィールドドメインは、通常はＭ２Ｍゲートウェイの背後にある、エリアネットワークを指す。フィールドドメインは、Ｍ２Ｍゲートウェイ１４と、端末デバイス１８とを含む。任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８が、所望に応じてＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれ得ることが理解されるであろう。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８の各々は、通信ネットワーク１２または直接無線リンクを介して、信号を伝送および受信するように構成される。Ｍ２Ｍゲートウェイデバイス１４は、無線Ｍ２Ｍデバイス（例えば、セルラーおよび非セルラー）ならびに固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が、通信ネットワーク１２等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかで、通信することを可能にする。例えば、Ｍ２Ｍデバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介して、データをＭ２Ｍアプリケーション２０もしくはＭ２Ｍデバイス１８に送信し得る。Ｍ２Ｍデバイス１８はまた、Ｍ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８からデータを受信し得る。さらに、データおよび信号は、以下で説明されるように、Ｍ２Ｍサービス層２２を介して、Ｍ２Ｍアプリケーション２０に送信され、そこから受信され得る。Ｍ２Ｍデバイス１８およびゲートウェイ１４は、例えば、セルラー、ＷＬＡＮ、ＷＰＡＮ（例えば、Ｚｉｇｂｅｅ（登録商標）、６ＬｏＷＰＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標））、直接無線リンク、および有線を含む、種々のネットワークを介して通信し得る。

図１７Ｂを参照すると、フィールドドメイン内の図示されるＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍ端末デバイス１８ならびに通信ネットワーク１２のためのサービスを提供する。Ｍ２Ｍサービス層２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、１つ以上のサーバ、コンピュータ等によって実装され得る。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで等の種々の方法で実装され得る。

図示されるＭ２Ｍサービス層２２と同様に、インフラストラクチャドメイン内にＭ２Ｍサービス層２２’がある。Ｍ２Ｍサービス層２２’は、インフラストラクチャドメイン内のＭ２Ｍアプリケーション２０’および下層通信ネットワーク１２’のためのサービスを提供する。Ｍ２Ｍサービス層２２’はまた、フィールドドメイン内のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８のためのサービスも提供する。Ｍ２Ｍサービス層２２’は、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス、およびＭ２Ｍ端末デバイスと通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２’は、異なるサービスプロバイダによってサービス層と相互作用し得る。Ｍ２Ｍサービス層２２’は、１つ以上のサーバ、コンピュータ、仮想マシン（例えば、クラウド／計算／記憶ファーム等）等によって実装され得る。

図１７Ｂも参照すると、Ｍ２Ｍサービス層２２および２２’は、多様なアプリケーションおよびバーティカルが活用することができる、サービス配信能力のコアセットを提供する。これらのサービス能力は、Ｍ２Ｍアプリケーション２０および２０’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、課金、サービス／デバイス発見等の機能を果たすことを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出すコストおよび時間を削減する。サービス層２２および２２’はまた、Ｍ２Ｍアプリケーション２０および２０’が、サービス層２２および２２’が提供するサービスと関連して、種々のネットワーク１２および１２’を通して通信することも可能にする。

いくつかの例では、Ｍ２Ｍアプリケーション２０および２０’は、本明細書で議論されるように、オープンメッセージバスアーキテクチャの１つ以上のコンポーネントを使用して通信する所望のアプリケーションを含み得る。Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界での用途を含み得る。上記のように、システムのデバイス、ゲートウェイ、および他のサーバを横断して起動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、サービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。

本願のオープンメッセージバスアーキテクチャの１つ以上のコンポーネントは、サービス層に関連して実装され得る。サービス層は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースの組を通して付加価値サービス能力をサポートするソフトウェアミドルウェア層である。Ｍ２Ｍエンティティ（例えば、ハードウェアおよびソフトウェアの組み合わせによって実装され得るデバイス、ゲートウェイ、またはサービス／プラットフォーム等のＭ２Ｍ機能エンティティ）は、アプリケーションまたはサービスを提供し得る。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍは両方とも、本願のオープンメッセージバスアーキテクチャの１つ以上のコンポーネントを含み得る、サービス層を使用する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内で実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）上でホストされることができる共通サービスエンティティ（ＣＳＥ）と称される。さらに、本願のオープンメッセージバスアーキテクチャの１つ以上のコンポーネントは、本願のオープンメッセージバスアーキテクチャの１つ以上のコンポーネント等のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／もしくはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装されることができる。

図１７Ｃは、Ｍ２Ｍ端末デバイス１８等の例示的Ｍ２Ｍデバイス３０の系統図である。図１７Ｃに示されるように、Ｍ２Ｍデバイス３０（例えば、場所追跡デバイス２２０）は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド４２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。Ｍ２Ｍデバイス３０は、開示される主題と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。Ｍ２Ｍデバイス３０（例えば、場所追跡デバイス２２０）は、オープンメッセージバスアーキテクチャのための開示されるシステムおよび方法を使用するデバイスであり得る。

プロセッサ３２は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態マシン等であり得る。プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはＭ２Ｍデバイス３０が無線環境で動作することを可能にする任意の他の機能性を果たし得る。プロセッサ３２は、伝送／受信要素３６に結合され得る送受信機３４に結合され得る。図１７Ｃは、プロセッサ３２および送受信機３４を別個のコンポーネントとして描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップにともに統合され得ることが理解されるであろう。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムならびに／もしくは通信を行い得る。プロセッサ３２は、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、ならびに／もしくは暗号化動作等のセキュリティ動作を行い得る。

伝送／受信要素３６は、信号をＭ２Ｍサービスプラットフォーム２２に伝送するか、またはＭ２Ｍサービスプラットフォーム２２から信号を受信するように構成され得る。例えば、伝送／受信要素３６は、ＲＦ信号を伝送および／または受信するように構成されるアンテナであり得る。伝送／受信要素３６は、ＷＬＡＮ、ＷＰＡＮ、セルラー等の種々のネットワークならびにエアインターフェースをサポートし得る。実施例では、伝送／受信要素３６は、例えば、ＩＲ、ＵＶ、もしくは可視光信号を伝送および／または受信するように構成されるエミッタ／検出器であり得る。さらに別の例では、伝送／受信要素３６は、ＲＦおよび光信号の両方を伝送ならびに受信するように構成され得る。伝送／受信要素３６は、無線もしくは有線信号の任意の組み合わせを伝送および／または受信するように構成され得ることが理解されるであろう。

加えて、伝送／受信要素３６は、単一の要素として図１７Ｃで描写されているが、Ｍ２Ｍデバイス３０は、任意の数の伝送／受信要素３６を含み得る。より具体的には、Ｍ２Ｍデバイス３０は、ＭＩＭＯ技術を採用し得る。したがって、実施例では、Ｍ２Ｍデバイス３０は、無線信号を伝送および受信するための２つ以上の伝送／受信要素３６（例えば、複数のアンテナ）を含み得る。

送受信機３４は、伝送／受信要素３６によって伝送される信号を変調するように、および伝送／受信要素３６によって受信される信号を復調するように構成され得る。上記のように、Ｍ２Ｍデバイス３０は、マルチモード能力を有し得る。したがって、送受信機３４は、Ｍ２Ｍデバイス３０が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１等の複数のＲＡＴを介して通信することを可能にするための複数の送受信機を含み得る。

プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の例では、プロセッサ３２は、サーバまたはホームコンピュータ上等のＭ２Ｍデバイス３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶し得る。プロセッサ３２は、本明細書に説明される実施例のうちのいくつかにおけるオープンメッセージバスアーキテクチャの１つ以上のコンポーネントが成功であるか、不成功であるか（例えば、サービス発見、サービスサブスクライブ等）に応答して、ディスプレイもしくはインジケータ４２上の照明パターン、画像、または色を制御するか、もしくは別様にオープンメッセージバスアーキテクチャの１つ以上のコンポーネントのステータスを示すように構成され得る。ディスプレイまたはインジケータ４２上の制御照明パターン、画像、もしくは色は、本明細書に図示または議論される図（例えば、図１−図１６）における方法フローもしくはコンポーネントのうちのいずれかのステータスを反映し得る。本明細書では、オープンメッセージバスアーキテクチャを作成して実装するためのメッセージおよびプロシージャが開示される。メッセージおよびプロシージャは、ユーザが、入力源（例えば、スピーカ／マイクロホン３８、キーパッド４０、またはディスプレイ／タッチパッド４２）を介してオープンメッセージバスを構成することを要求し、ディスプレイ４２上に表示され得るものでもとりわけ、オープンメッセージバス関連メッセージを要求、構成、またはクエリするために、インターフェース／ＡＰＩを提供するように拡張されることができる。

プロセッサ３２は、電源４８から電力を受け取り得、Ｍ２Ｍデバイス３０内の他のコンポーネントへの電力を分配および／または制御するように構成され得る。電源４８は、Ｍ２Ｍデバイス３０に給電するための任意の好適なデバイスであり得る。例えば、電源４８は、１つ以上の乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池等を含み得る。

プロセッサ３２はまた、Ｍ２Ｍデバイス３０の現在の場所に関する場所情報（例えば、経度および緯度）を提供するように構成される、ＧＰＳチップセット５０に結合され得る。Ｍ２Ｍデバイス３０は、本明細書に開示される情報と一致したままで、任意の好適な場所決定方法を介して場所情報を獲得し得ることが理解されるであろう。

プロセッサ３２はさらに、追加の特徴、機能性、および／または有線もしくは無線コネクティビティを提供する、１つ以上のソフトウェアならびに／もしくはハードウェアモジュールを含み得る他の周辺機器５２に結合され得る。例えば、周辺機器５２は、加速度計、ｅ−コンパス、衛星送受信機、センサ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ等を含み得る。

図１７Ｄは、例えば、図１７Ａおよび１７ＢのＭ２Ｍサービスプラットフォーム２２が実装され得る例示的コンピューティングシステム９０のブロック図である。コンピューティングシステム９０は、コンピュータまたはサーバを備え得、主に、そのようなソフトウェアが記憶またはアクセスされる場所もしくは手段にかかわらず、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得る。そのようなコンピュータ読み取り可能な命令は、コンピューティングシステム９０を稼働させるように、中央処理装置（ＣＰＵ）９１内で実行され得る。多くの既知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を果たす、またはＣＰＵ９１を補助する、主要ＣＰＵ９１とは明確に異なる、随意のプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、メッセージバスバックボーンに関連付けられるサービスをブラウズするためのＤＮＳ−ＳＤメッセージを受信すること等、オープンメッセージバスアーキテクチャの１つ以上のコンポーネントのための開示されるシステムおよび方法に関連するデータを受信、生成、および処理し得る。

動作時、ＣＰＵ９１は、命令をフェッチ、デコード、および実行し、コンピュータの主要データ転送パスであるシステムバス８０を介して、情報を他のリソースへ、ならびにそこから転送する。そのようなシステムバスは、コンピューティングシステム９０内のコンポーネントを接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送信するためのデータラインと、アドレスを送信するためのアドレスラインと、インタラプトを送信するため、およびシステムバスを動作させるための制御ラインとを含む。そのようなシステムバス８０の例は、ＰＣＩ（周辺コンポーネント相互接続）バスである。

システムバス８０に結合されるメモリデバイスは、ランダムアクセスメモリ（ＲＡＭ）８２と、読み取り専用メモリ（ＲＯＭ）９３とを含む。そのようなメモリは、情報が記憶されて読み出されることを可能にする回路を含む。ＲＯＭ９３は、概して、容易に修正されることができない、記憶されたデータを含む。ＲＡＭ８２に記憶されたデータは、ＣＰＵ９１または他のハードウェアデバイスによって読み取られるか、または変更されることができる。ＲＡＭ８２および／またはＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御され得る。メモリコントローラ９２は、命令が実行されると、仮想アドレスを物理的アドレスに変換する、アドレス変換機能を提供し得る。メモリコントローラ９２はまた、システム内のプロセスを隔離し、ユーザプロセスからシステムプロセスを隔離する、メモリ保護機能を提供し得る。したがって、第１のモードで起動するプログラムは、独自のプロセス仮想アドレス空間によってマップされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることができない。

加えて、コンピューティングシステム９０は、ＣＰＵ９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５等の周辺機器に命令を通信する責任がある、周辺機器コントローラ８３を含み得る。

ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピューティングシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために必要とされる、電子コンポーネントを含む。

さらに、コンピューティングシステム９０は、図１７Ａおよび１７Ｂのネットワーク１２等の外部通信ネットワークにコンピューティングシステム９０を接続するために使用され得る、ネットワークアダプタ９７を含み得る。

図１８は、本明細書で議論される方法およびシステムに基づいて生成され得る例示的ディスプレイ（例えば、グラフィカルユーザインターフェース）を図示する。ディスプレイインターフェース９０１（例えば、タッチスクリーンディスプレイ）は、表１から表２５のパラメータ等のメッセージバスサービスディレクトリに関連付けられるブロック９０２内でテキストを提供し得る。別の実施例では、本明細書で議論されるステップのうちのいずれかの進捗（例えば、送信されたメッセージまたはステップの成功）は、ブロック９０２内で表示され得る（例えば、図１０−図１５）。加えて、グラフィカル出力９０３が、（例えば、図１−図１７Ｄに関連付けられる）ディスプレイインターフェース９０１上に表示され得る。グラフィカル出力９０３は、クラスタ内のデバイスのトポロジ、本明細書で議論される任意の方法またはシステムの進捗のグラフィカル出力等であり得る。例えば、グラフィックユーザインターフェースを用いた管理サービス２５０（図８参照）が、ＯＭＢに接続するクライアントサービスを管理および監視するために使用され得る。管理サービス２５０は、メッセージバスサービスディレクトリの構成および監視のために使用され得る。

本明細書に説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、命令が、コンピュータ、サーバ、Ｍ２Ｍ端末デバイス、Ｍ２Ｍゲートウェイデバイス等のマシンによって実行されると、本明細書に説明されるシステム、方法、およびプロセスを実施ならびに／または実装する、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形態で具現化され得ることが理解される。具体的には、上記で説明されるステップ、動作、または機能のうちのいずれも、そのようなコンピュータ実行可能命令の形態で実装され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の方法または技術で実装される、揮発性および不揮発性の取り外し可能および非取り外し可能媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、信号を含まない。コンピュータ読み取り可能な記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイス、もしくは所望の情報を記憶するために使用することができ、コンピュータによってアクセスされることができる任意の他の物理的媒体を含むが、それらに限定されない。

図で図示されるような本開示の主題の好ましい方法、システム、または装置を説明する際に、具体的用語が、明確にするために採用される。しかしながら、請求される主題は、そのように選択された具体的用語に限定されることを意図せず、各具体的要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。

本明細書は、最良の様態を含む、本発明を開示するために、また、当業者が、任意のデバイスまたはシステムを作製して使用すること、および任意の組み込まれた方法を行うことを含む、本発明を実践することを可能にするために、実施例を使用する。本発明の特許性のある範囲は、請求項によって定義され、他の実施例を含み得る（例えば、本明細書に開示される例示的方法の間でステップを省略する、ステップを組み合わせる、またはステップを追加する）。そのような他の実施例は、請求項の文字通りの用語と異ならない構造要素を有する場合、または請求項の文字通りの用語からごくわずかな差異を伴う同等の構造要素を含む場合、請求項の範囲内であることを意図している。以下で議論されるような方法、システム、コンピュータ読み取り可能な記憶媒体、装置等に関する要素の全ての組み合わせが、発明を実施するための形態の他の部分と一致する様式で考慮される。

方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、メッセージブローカに関連付けられている利用可能なサービスについての情報に対する要求を送信し、利用可能なサービスの記述を含む応答を受信し、応答からの利用可能なサービスのうちの第１の利用可能なサービスを選択し、応答内の第１の利用可能なサービスの記述に基づいて、メッセージブローカと接続する手段を有する。情報に対する要求は、ポインタレコードに対するＤＮＳ−ＳＤルックアップを含み得る。応答は、ＤＮＳ−ＳＤ応答であり得る。

方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、メッセージブローカを介して利用可能なサービスを分類するサービスディレクトリに、第１のサービスであって、メッセージブローカと接続される第１のサービスのプロファイルをロードし、サービスディレクトリをブラウズするように、第２のサービスによる要求を受信し、第２のサービスから、メッセージブローカと接続する要求を受信し、メッセージブローカを介して第１のサービスを第２のサービスに接続する手段を有する。サービスディレクトリをブラウズする要求は、ＤＮＳ−ＳＤインターフェースに関連付けられ得る。メッセージブローカは、管理サービスと接続され得る。メッセージブローカは、データベースサービスと接続され得る。第１のサービスは、メッセージバスクライアントと接続されるアプリケーションプログラミングインターフェースを介して、メッセージブローカと接続され得る。第１のサービスがメッセージブローカと切断するとき、第２のサービスの通知があり得る。一致しているプロファイルを有する第３のサービスがメッセージブローカと接続するときに通知を受信するように、第２のサービスによるサブスクライブがあり得る。

方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、メッセージブローカを介して、第１のサービスを第２のサービスと接続し、状態が第２のサービスまたは第３のサービスとともに変化するとき、もしくは状態がメッセージブローカと接続されるサービスのクラスとともに変化するとき、第１のサービスに通知するための命令を含む要求を第１のサービスによって送信する手段を有する。状態変化は、第２のサービスまたは第３のサービスのサービスプロファイルの削除、作成、もしくは更新を含み得る。状態変化は、第２のサービスまたは第３のサービスの削除、作成、もしくは更新を含み得る。

方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、第１のサービスが複数のサービスを記述するプロファイルを管理する、第１のサービス、第１のサービスと通信可能に接続されるメッセージバスクライアント、および第１のサービスならびにメッセージバスクライアントであって、第１のサービスがメッセージバスと接続するためにアプリケーションプログラミングインターフェース（ＡＰＩ）を提供する、メッセージバスクライアントと通信可能に接続されるメッセージブローカのための手段を有する。ＡＰＩは、第１のサービスがサービス識別子またはサービスタイプ識別子でそれ自体を識別することを可能にし得る。ＡＰＩは、ＡＰＩ要求がブロッキングまたは非ブロッキングであるかどうかを第１のサービスが示すことを可能にし得る。ＡＰＩは、第１のサービスが、トークン値、関数名、または各ＡＰＩコールもしくは各非ブロッキングＡＰＩコールのための関数へのポインタを提供することを可能にし得る。トークンは、応答を元のＡＰＩコールと相関させるために第１のサービスによって使用され得る。ＡＰＩは、第１のサービスが、非ブロッキング要求に戻るときにどのような関数が呼び出されているかを示すことを可能にし得る。ＡＰＩは、第１のサービスとメッセージブローカとの間で使用される下層トランスポートプロトコルに特定のコマンドを実行することなく、第１のサービスがメッセージブローカと通信するためのコマンドの組を提供し得る。

Claims (20)

1. デバイスであって、前記デバイスは、
   プロセッサと、
   前記プロセッサと接続されているメモリと
   を備え、
   前記メモリは、実行可能命令を含み、前記命令は、前記プロセッサによって実行されると、
   メッセージブローカに関連付けられている利用可能なサービスについての情報を要求することと、
   前記利用可能なサービスの記述を含む応答を受信することと、
   前記応答からの前記利用可能なサービスのうちの第１のサービスを精査することと、
   前記応答内の前記第１のサービスの前記記述に基づいて、前記メッセージブローカと接続することと
   を含む動作を前記プロセッサに達成させる、デバイス。
2. 前記利用可能なサービスの前記記述を含む前記応答は、前記メッセージブローカと接続されているサービスディレクトリからである、請求項１に記載のデバイス。
3. 前記サービスディレクトリは、メッセージブローカを介して利用可能な前記サービスを分類している、請求項２に記載のデバイス。
4. 前記サービスディレクトリをブラウズするための前記要求は、ＤＮＳ−ＳＤインターフェースに関連付けられている、請求項２に記載のデバイス。
5. 情報に対する前記要求は、ポインタレコードに対するＤＮＳ−ＳＤルックアップを備えている、請求項１に記載のデバイス。
6. 前記応答は、ＤＮＳ−ＳＤ応答である、請求項１に記載のデバイス。
7. 前記動作は、前記第１のサービスのためのＤＮＳサービス場所レコードを送信することをさらに含む、請求項１に記載のデバイス。
8. 前記メッセージブローカは、トランスポートに依存しないアプリケーションプログラミングインターフェースを介して接続する、請求項１に記載のデバイス。
9. 前記動作は、一致しているプロファイルを有する第２の利用可能なサービスが前記メッセージブローカと接続するときに通知を受信するためにサブスクライブすることをさらに含む、請求項１に記載のデバイス。
10. 方法であって、前記方法は、
    メッセージブローカに関連付けられている利用可能なサービスについての情報を第１のサービスから要求することと、
    前記利用可能なサービスの記述を含む応答を受信することと、
    前記応答からの前記利用可能なサービスのうちの第２のサービスを精査することと、
    前記応答内の前記第２のサービスの前記記述に基づいて、前記メッセージブローカと接続することと
    を含む、方法。
11. 情報に対する前記要求は、ポインタレコードに対するＤＮＳ−ＳＤルックアップを備えている、請求項１０に記載の方法。
12. 前記応答は、ＤＮＳ−ＳＤ応答である。請求項１０に記載の方法。
13. 前記動作は、前記第２のサービスのためのＤＮＳサービス場所レコードを送信することをさらに含む、請求項１０に記載の方法。
14. 前記メッセージブローカは、トランスポートに依存しないアプリケーションプログラミングインターフェースを介して接続する、請求項１０に記載の方法。
15. 前記動作は、一致しているプロファイルを有する第３のサービスが前記メッセージブローカと接続するときに通知を受信するためにサブスクライブすることをさらに含む、請求項１０に記載の方法。
16. 前記動作は、前記第２のサービスが前記メッセージブローカと切断するとき、前記第１のサービスに通知することをさらに含む、請求項１０に記載の方法。
17. コンピュータ実行可能命令を備えているコンピュータ読み取り可能な媒体であって、前記命令は、コンピュータデバイスによって実行されると、
    メッセージブローカに関連付けられている利用可能なサービスについての情報を要求することと、
    前記利用可能なサービスの記述を含む応答を受信することと、
    前記応答からの前記利用可能なサービスのうちの第１のサービスを精査することと、
    前記応答内の前記第１のサービスの前記記述に基づいて、前記メッセージブローカと接続することと
    を含む動作を前記コンピュータデバイスに達成させる、コンピュータ読み取り可能な記憶媒体。
18. 利用可能なサービスの前記説明を含む前記応答は、前記メッセージブローカと接続されているサービスディレクトリからである、請求項１７に記載のデバイス。
19. 前記サービスディレクトリは、メッセージブローカを介して利用可能な前記サービスを分類している、請求項１８に記載のデバイス。
20. 前記サービスディレクトリをブラウズするための前記要求は、ＤＮＳ−ＳＤインターフェースに関連付けられている、請求項１８に記載のデバイス。