JP7142641B2 - ネットワークサービス層における分散トランザクション管理 - Google Patents

Description

（関連出願の相互参照）
本出願は、２０１７年３月１７日に出願された「ＩｏＴ（Internet of Things）サービス層における分散トランザクション管理を可能にする方法」と題する米国仮出願第６２／４７２，８５１号の利益を主張するものであり、その内容はその全体が参照により本明細書に組み込まれる。

（背景）
トランザクションは、ユニットとして実行される必要のある、操作のセット、または操作のシーケンスである場合がある。操作のセットは、（例えば、機能上の理由またはビジネス上の理由により）密接に関係する場合があり、またユニットとして各操作の全てが正常に実行されるか、または該各操作のいずれも実行されないかのどちらか一方である必要がある。トランザクションは、原子性、一貫性、独立性、および耐久性（Atomicity, Consistency, Isolation and Durability：ＡＣＩＤ）の４つの特性を有する場合がある。原子性とは、トランザクションにリクエストまたはステップがいくつ含まれても、それらが単一のリクエストであるかのように実行される必要があることを意味する。それらは全てが正常に実行されるか、または全く実行されない必要がある。部分的な実行は許容されない。一貫性とは、トランザクションの実行前と実行後とで、トランザクションのターゲットの状態が一貫していなければならないことを意味する。一貫性は、原子性と密接に関係している。独立性とは、各トランザクションが互いに独立している必要があり、互いに干渉できないことを意味する。耐久性とは、一旦トランザクションがコミットされると、システムはトランザクションの結果が安全で耐久性のあるものであることを保証する必要があることを意味する。結果は、突然の誤動作に耐え得るものであり、回復後の結果に回復できるものである。近年、マシンツーマシン（Machine-To-Machine：Ｍ２Ｍ）ネットワークまたはＩｏＴ（Internet of Things）ネットワークのコンテキストにおけるトランザクション処理に取り組む努力がなされている。

通信ネットワークのサービス層での分散トランザクション処理のサポートを提供するための方法、装置、およびシステムを本明細書にて開示する。方法、装置およびシステムは、ＤＳＬＴの処理をそれら自体で管理しなければならないというアプリケーションの複雑さおよび負担を軽減するために、分散サービス層トランザクション（Distributed Service Layer Transaction：ＤＳＬＴ）処理性能をサポートするＤＳＬＴサービスで具現化することができる。ＤＳＬＴ処理性能は、アプリケーションに代わってＤＳＬＴの原子的処理を管理するＤＳＬＴサービス性能と、アプリケーションに代わってＤＳＬＴシーケンスの原子的処理を管理するＤＳＬＴサービス性能と、ＤＳＬＴまたはＤＳＬＴシーケンスを構成する個々のリクエストのスケジューリングを調整するＤＳＬＴサービス性能と、ＤＳＬＴまたはＤＳＬＴシーケンスの実行基準をアプリケーションが定義できるようにするＤＳＬＴサービス性能と、ＤＳＬＴまたはＤＳＬＴシーケンスの再伝送ポリシーをアプリケーションが定義できるようにするＤＳＬＴサービス性能と、ＤＳＬＴまたはＤＳＬＴシーケンスの完了基準をアプリケーションが定義できるようにするＤＳＬＴサービス性能と、ＤＳＬＴまたはＤＳＬＴシーケンスの優先順位をアプリケーションが定義できるようにするＤＳＬＴサービス性能と、ＤＳＬＴまたはＤＳＬＴシーケンスを開始するためのシンプルなＲＥＳＴｆｕｌアプリケーションプログラミングインターフェース（Application Programming Interface：ＡＰＩ）をアプリケーションに提供するＤＳＬＴサービス性能とを含んでよい。

一態様では、ＤＳＬＴサービスを実装する通信ネットワークの第１サービス層エンティティは、通信ネットワーク上で実行されるアプリケーションから分散トランザクションのリクエストを受信してよい。リクエストは、該通信ネットワークの複数の他のサービス層エンティティによってホストされているターゲットリソースのセットで原子的に実行されるコマンドを規定してよい。リクエストに応答して、第１サービス層エンティティは、複数の他のサービス層エンティティのそれぞれに、該他のサービス層エンティティによってホストされているターゲットリソースのいずれかをロックするようにリクエストを送信してよい。次いで、第１サービス層エンティティは、複数の他のサービス層エンティティのそれぞれから、該サービス層エンティティがそのサービス層エンティティによってホストされているターゲットリソースをロックできたかどうかを示す応答を受信してよい。第１サービス層エンティティが、ターゲットリソースの全てがロックされたことを示す応答を受信する場合、第１サービス層エンティティは、ターゲットリソースのセットでコマンドの原子的実行を実施するように、複数の他のサービス層エンティティにリクエストを送信してよい。第１サービス層エンティティが、コマンドがターゲットリソースのセットで正常に実行されたことを示す応答を受信する場合、第１サービス層エンティティは、分散トランザクションをコミットするように、複数の他のサービス層エンティティにリクエストを送信してよい。次に、第１サービス層エンティティは、アプリケーションに分散トランザクションが正常に実施されたことを示す応答を送信してよい。

別の態様では、第１サービス層エンティティは、アプリケーションから分散トランザクションのリクエストを受信すると、第１サービス層エンティティのメモリ内に、分散トランザクションを表し、かつ分散トランザクションの状態に関する情報を含むリソースを生成してもよい。当該リソースは、アプリケーションがトランザクションのステータスを監視できるように、アプリケーションが通信ネットワークを介してアクセス可能なものであってよい。当該リソースは、トランザクションを一意に識別するトランザクション識別子属性と、分散トランザクションの状態に関する情報が保存されているトランザクション状態属性を含んでよい。当該リソースは、第１サービス層エンティティが分散トランザクションのリクエストの処理をいつ開始するかを制御する実行時間属性をさらに含んでもよい。

本概要は、一部の概念を簡単に紹介するものであり、詳しくは以下の詳細な説明で説明する。本概要は、請求の範囲に記載される主題の主要な特徴または実質的な特徴を特定することも、請求の範囲に記載される主題の範囲を限定するために使用されることも意図していない。さらに、請求の範囲に記載される主題は、本開示のいずれかの部分に記載される、不利点の一部またはすべてを解決する限定事項にも限定されない。

添付図面と併せて例として挙げられる以下の説明からより詳細な理解を得ることが可能である。

図１は、サービス層をサポートする例示的プロトコルスタックを示す図である。 図２は、様々な種類のネットワークノードに展開されるＭ２Ｍ／ＩｏＴサービス層（Service Layer：ＳＬ）を示す図である。 図３は、ｏｎｅＭ２Ｍアーキテクチャを示す図である。 図４は、ｏｎｅＭ２Ｍ共通サービス機能を示す図である。 図５は、ｏｎｅＭ２Ｍアーキテクチャによってサポートされる構成を示す図である。 図６は、ｏｎｅＭ２Ｍ＜ｔｒａｎｓａｃｔｉｏｎ＞リソースを示す図である。 図７は、ｏｎｅＭ２Ｍトランザクション処理（成功例）を示す図である。 図８は、ｏｎｅＭ２Ｍトランザクション処理（失敗例）を示す図である。 図９は、ＳＬトランザクション管理の有用性を説明するスマートファクトリーユースケースを示す図である。 図１０は、分散サービス層トランザクション（ＤＳＬＴ）の最小限のＳＬソリューションを示す図である。 図１１は、ＤＳＬＴの完全なＳＬソリューションを示す図である。 図１２は、ＤＳＬＴ展開オプションを示す図である。 図１３は、分散サービス層トランザクション管理機能（Distributed Service Layer Transaction Management Function：ＤＳＬＴ－ＭＦ）を示す図である。 図１４は、分散サービス層トランザクションクライアント機能（Distributed Service Layer Transaction Client Function：ＤＳＬＴ－ＣＦ）を示す図である。 図１５は、個々のＤＳＬＴに対する分散サービス層トランザクショントリガ機能（Distributed Service Layer Transaction Trigger Function：ＤＳＬＴ－ＴＦ）の処理を示す図である。 図１６は、個々のＤＳＬＴに対するＤＳＬＴ－ＭＦの処理を示す図である。 図１７は、個々のＤＳＬＴ－ＣＦに対するＤＳＬＴ－ＣＦの処理を示す図である。 図１８は、ＤＳＬＴシーケンスに対するＤＳＬＴ－ＴＦの処理を示す図である。 図１９は、ＤＳＬＴシーケンスに対するＤＳＬＴ－ＭＦの処理を示す図である。 図２０は、ＤＳＬＴシーケンスに対するＤＳＬＴ－ＣＦの処理を示す図である。 図２１は、個々のＤＳＬＴプロシージャを示す図である。 図２２は、ＤＳＬＴシーケンスプロシージャを示す図である。 図２３は、ｏｎｅＭ２Ｍにおけるトランザクション管理共通サービス機能（Common Service Functions：ＣＳＦ）のアーキテクチャの実施形態を示す図である。 図２４は、ｏｎｅＭ２ＭリソースのＤＳＬＴ指向属性を示す図である。 図２５は、ｏｎｅＭ２Ｍ ＤＳＬＴシーケンスリソースを示す図である。 図２６は、ｏｎｅＭ２Ｍ＜ｇｒｏｕｐ＞リソースのＤＳＬＴ拡張を示す図である。 図２７－１は、ｏｎｅＭ２Ｍ ＤＳＬＴグループファンアウト（ｆａｎｏｕｔ）プロシージャを示す図である。 図２７－２は、ｏｎｅＭ２Ｍ ＤＳＬＴグループファンアウト（ｆａｎｏｕｔ）プロシージャを示す図である。 図２８－１は、ｏｎｅＭ２Ｍ ＤＳＬＴシーケンスプロシージャを示す図である。 図２８－２は、ｏｎｅＭ２Ｍ ＤＳＬＴシーケンスプロシージャを示す図である。 図２９は、サービス層トランザクションユーザーインターフェースを示す図である。 図３０Ａは、通信ネットワークを含むＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システムを示す図である。 図３０Ｂは、Ｍ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス、およびＭ２Ｍ端末デバイスならびに通信ネットワークにサービスを提供するフィールドドメインにおけるＭ２Ｍサービス層を示す図である。 図３０Ｃは、本明細書で記載される論理的エンティティのいずれかを実装するために使用することができる例示的装置を示す図である。 図３０Ｄは、本明細書で記載される論理的エンティティのいずれかを実装するために使用することができるコンピュータシステムまたはサーバのブロック図である。

以下は、以下の説明に出現する可能性のある頭字語のリストである。特に指示がない限り、本明細書で使用される頭字語は、以下に記載された対応する用語を指す。
ＡＤＮ：Application Dedicated Node（アプリケーション専用ノード）
ＡＥ：Application Entity（アプリケーションエンティティ）
ＡＰＩ：Application Programming Interfaces（アプリケーションプログラミングインターフェース）
ＡＳＮ：Application Service Node（アプリケーションサービスノード）
ＣＳＥ：Common Service Entity（共通サービスエンティティ）
ＣＳＦ：Common Service Function（共通サービス機能）
ＤＳＬＴ：Distributed Service Layer Transaction（分散サービス層トランザクション）
ＤＳＬＴ－ＣＦ：Distributed Service Layer Transaction Client Function（分散サービス層トランザクションクライアント機能）
ＤＳＬＴ－ＭＦ：Distributed Service Layer Transaction Management Function（分散サービス層トランザクション管理機能）
ＤＳＬＴ－ＴＦ：Distributed Service Layer Transaction Trigger Function（分散サービス層トランザクショントリガ機能）
ＤＳＬＴ－ＲＥＱ：Distributed Service Layer Transaction Request（分散サービス層トランザクションリクエスト）
ＤＳＬＴ－ＴＲＩＧＧＥＲ：Distributed Service Layer Transaction Trigger Request（分散サービス層トランザクショントリガリクエスト）
ＩＮ：Infrastructure Network（インフラストラクチャネットワーク）
ＩｏＴ：Internet of Things（モノのインターネット）
ＩＰ：Internet Protocol（インターネットプロトコル）
Ｍ２Ｍ：Machine to Machine（マシンツーマシン）
ＭＮ：Middle Node（ミドルノード）
ＮｏＤＮ：Non-oneM2M Node（非ｏｎｅＭ２Ｍノード）
ＰｏＡ：Point of Access（アクセスポイント）
ＲＯＡ：Resource Oriented Architecture（リソース指向アーキテクチャ）
ＳＬ：Service Layer（サービス層）
ＵＲＩ：Uniform Resource Identifier（ユニフォームリソース識別子）

また、以下の用語は、以下の説明で使用される場合があり、特に指示がない限り以下の意味を含んでよい。

Ｍ２Ｍ／ＩｏＴサービス層は、アプリケーションプログラミングインターフェース（ＡＰＩ）と下位ネットワークインターフェースとのセットを介してＭ２Ｍ／ＩｏＴアプリケーションおよびデバイス向けに付加価値サービスをサポートするソフトウェアミドルウェア層であってよい。

Ｍ２Ｍ／ＩｏＴアプリケーションは、特定のＭ２Ｍ／ＩｏＴユースケース（例えば、ｅヘルス、スマートエネルギー、ホームオートメーション）を対象とするアプリケーションであってよい。

サービス層エンティティは、Ｍ２Ｍ／ＩｏＴアプリケーション、またはＭ２Ｍ／ＩｏＴサービス層のインスタンスであってよい。

サービス層リソースは、Ｍ２Ｍ／ＩｏＴサービス層によってホストされる一意にアドレス付け可能なオブジェクトであってよい。

サービス層リクエストは、サービス層リソースを対象とするサービス層エンティティによって送出される操作であってよい。

サービス層トランザクションは、全てが正常に実行されるか、またはいずれも実行されない、ユニットとして原子的に実施される必要があるサービス層リクエストのセットまたはシーケンスであってよい。

分散サービス層トランザクションは、異なるネットワークノードでホストされる複数のサービス層エンティティによってホストされるリソースのセットを対象とするサービス層トランザクションであってよい。

分散サービス層トランザクション管理機能は、分散サービス層トランザクションクライアント機能と相互作用でき、かつこれらの機能への分散サービス層トランザクションの原子的な処理を管理できるサービス層機能であってよい。

分散サービス層トランザクションクライアント機能は、分散サービス層トランザクション管理機能と相互作用でき、かつ個々の分散サービス層トランザクションを受信して処理できるサービス層機能であってよい。

分散サービス層トランザクショントリガ機能は、分散サービス層トランザクション管理機能と相互作用でき、かつ分散サービス層トランザクションを開始できるサービス層機能であってよい。

分散サービス層トランザクショントリガリクエストは、分散サービス層トランザクショントリガ機能によって分散サービス層トランザクション管理機能に送信され、分散サービス層トランザクションを開始させるリクエストであってよい。

分散サービス層トランザクションリクエストは、分散サービス層トランザクション管理機能によって分散サービス層トランザクションクライアント機能に配布され、分散サービス層トランザクションを実行させるリクエストであってよい。

Ｍ２Ｍ（Machine-To-Machine）ネットワークまたはＩｏＴ（Internet of Things）ネットワークでは、サービス層（ＳＬ）は、特に、Ｍ２Ｍ／ＩｏＴデバイスおよびＭ２Ｍ／ＩｏＴアプリケーション向けに付加価値サービスを提供することを目的とする技術である。近年、いくつかの業界規格団体（例えば、ｏｎｅＭ２Ｍ[oneM2M TS-0001 oneM2M Functional Architecture-V-3.0.0.]、ＥＴＳＩ[ETSI TS 102 690 Machine-to-Machine communications (M2M) Functional architecture V2.0.13.]、ＯＣＦ[OCF - OIC Specifications, V1.1]、およびＬＷＭ２Ｍ[OMA LWM2M Specification,V1.0]）が、インターネット／ウェブ、セルラー、企業内、および家庭内のネットワーク展開へのＭ２Ｍ／ＩｏＴデバイスおよびアプリケーションの統合に関連する課題に対処するためにＭ２Ｍ／ＩｏＴ ＳＬを開発している。

Ｍ２Ｍ／ＩｏＴサービス層は、アプリケーションおよびデバイスがＭ２Ｍ／ＩｏＴ指向性能群にアクセスできるようにする。いくつかの例としては、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニングおよび接続管理が挙げられる。これらの性能は、Ｍ２Ｍ／ＩｏＴ ＳＬによってサポートされるメッセージフォーマット、リソース構成およびリソース表現を利用するアプリケーションプログラミングインターフェース（ＡＰＩ）を介してアプリケーションが利用できるものである。

プロトコルスタックの観点から、ＳＬは典型的には、アプリケーションプロトコル層の上位に位置し、サポートしているアプリケーションに付加価値サービスを提供する。それゆえＳＬは、「ミドルウェア」サービスとして分類されることが多い。図１は、アプリケーションプロトコル１０４とアプリケーション１０６との間の例示的なサービス層１０２を示す図である。

展開の観点から、Ｍ２Ｍ／ＩｏＴ ＳＬ１０２は、図２に示すように、サーバ、ゲートウェイ、およびデバイスを含む様々な種類のネットワークノードで展開され得る。サービス層機能を実装またはサービス層のインスタンスを組み込む通信ネットワークのノード、サーバ、ゲートウェイ、デバイス、装置、または他の論理的エンティティはいずれも、本明細書においてはサービス層エンティティと称する場合がある。

ｏｎｅＭ２Ｍ規格[oneM2M TS-0001]では、のｅ－ヘルス、フリート管理、およびスマートホームなどの様々な「バーティカル」なＭ２Ｍシステムおよびアプリケーションによって利用することができる「ホリゾンタル」なサービスを提供することを目的とするＭ２Ｍ／ＩｏＴ ＳＬを定義している。ｏｎｅＭ２Ｍ ＳＬのアーキテクチャは、図３に示すように、サービス層を採り入れて、４つの参照点をサポートする共通サービスエンティティ（Common Service Entity：ＣＳＥ）３０２を画定する。Ｍｃａ参照点は、アプリケーションエンティティ（Application Entity：ＡＥ）３０４とインターフェースする。Ｍｃｃ参照点は、同一サービスプロバイダドメイン内の別のＣＳＥ３０６とインターフェースし、Ｍｃｃ’参照点は、異なるサービスプロバイダドメインの別のＣＳＥとインターフェースする。Ｍｃｎ参照点は、下位ネットワークサービスエンティティ（Network Service Entity：ＮＳＥ）とインターフェースする。ＮＳＥ３０８は、デバイス管理、位置情報サービス、およびデバイストリガ等の下位ネットワークサービスをＣＳＥに提供する。ＣＳＥは、「発見」、「データ管理およびリポジトリ」などの「共通サービス機能（ＣＳＦ）」と呼ばれる複数の論理機能を含み、これらの機能を合わせてサービス層の機能が構成される。図４はｏｎｅＭ２ＭによってサポートされるＣＳＦを示す図である。通信ネットワークのノード、サーバ、ゲートウェイ、デバイス、装置、またはその他の論理的エンティティでホストされるＣＳＥの各インスタンスは、本明細書においてはネットワークのサービス層エンティティと称する場合がある。

ｏｎｅＭ２Ｍアーキテクチャは、分散型アーキテクチャであり、Ｍ２Ｍ／ＩｏＴサービスを以下の種類のノードにわたって分散して展開することをサポートする。
・アプリケーションサービスノード（ＡＳＮ）
ＡＳＮは、１つのＣＳＥを含み、かつ少なくとも１つのアプリケーションエンティティ（ＡＥ）を含むノードである。例えば、ＡＳＮは、Ｍ２Ｍデバイス内に存在し得る。
・アプリケーション専用ノード（ＡＤＮ）
ＡＤＮは、少なくとも１つのＡＥを含み、ＣＳＥを含まないノードである。例えば、アプリケーション専用ノードは、制約されたＭ２Ｍデバイス内に存在し得る。
・ミドルノード（ＭＮ）
ＭＮは、１つのＣＳＥを含み、かつゼロ以上のＡＥを含むノードである。例えば、ＭＮは、Ｍ２Ｍゲートウェイに存在し得る。
・インフラストラクチャノード（ＩＮ）
ＩＮは、１つのＣＳＥを含み、かつゼロ以上のＡＥを含むノードである。ＩＮ内のＣＳＥは、他のノードタイプには適用されないＣＳＥ機能を含む場合がある。例えば、ＩＮは、Ｍ２Ｍサービスインフラストラクチャ内に存在し得る。
・非ｏｎｅＭ２Ｍノード（ＮｏＤＮ）
非ｏｎｅＭ２Ｍノードは、ｏｎｅＭ２Ｍエンティティを（ＡＥおよびＣＳＥのいずれも）含まないノードである。このようなノードは、管理を含む相互動作目的のためにｏｎｅＭ２Ｍシステムに接続されたデバイスを意味する。

ｏｎｅＭ２Ｍシステム内でサポートされる種々のエンティティを相互接続する可能な構成を図５に示す。

近年、ｏｎｅＭ２ＭはＳＬトランザクション向けのサポートを規定する取り組みを開始している。この取り組みは、oneM2M TR-0020, Study of service transactions and re-usable service layer context, V0.6.0に記載されている。現在までのところ、これまでに１つのソリューションが定義されている。以下はこのソリューションの概要である。

＜ｔｒａｎｓａｃｔｉｏｎ＞リソースは他のいずれかのリソースの子であり得る。これは、親リソースがトランザクションのターゲットであることを意味する。＜ｔｒａｎｓａｃｔｉｏｎ＞リソースの状態に基づいて、ｏｎｅＭ２Ｍプリミティブはターゲットリソースで実行される。＜ｔｒａｎｓａｃｔｉｏｎ＞リソースの構成を図６に示し、その属性を表１で説明する。

図７および図８は、ｏｎｅＭ２Ｍシステムにおいて、＜ｔｒａｎｓａｃｔｉｏｎ＞リソースを使用して、どのようにトランザクションが処理されるかのフローを示す図である。図７は、ｏｎｅＭ２Ｍトランザクション処理の成功例を示す図である。図８は、ｏｎｅＭ２Ｍトランザクション処理の失敗例を示す図である。この処理は、１つのＡＥおよび複数のＣＳＥによって行われる。ＡＥは、複数のＣＳＥにわたるトランザクションの調整を開始および管理する。各ステップの詳細な説明を以下に示す。

図７および図８のステップ１では、ＡＥ７０２は、複数のＣＳＥに＜ｔｒａｎｓａｃｔｉｏｎ＞リソースを生成する。＜ｔｒａｎｓａｃｔｉｏｎ＞は、各ターゲットリソースの子リソースとして生成される。＜ｔｒａｎｓａｃｔｉｏｎ＞リソースは、トランザクションの実行時間、および実行されるプリミティブを含む。トランザクションのコミットが調整されることを保証するために、それぞれのＣＳＥの実行時間は同じである。プリミティブは、発信元の識別情報、操作、および実行されるプリミティブの内容をさらに含む。

図７および図８のステップ２では、＜ｔｒａｎｓａｃｔｉｏｎ＞生成リクエストを受信した各ＣＳＥ７０４、７０６および７０８において、ＣＳＥ７０４、７０６および７０８は、＜ｔｒａｎｓａｃｔｉｏｎ＞を正常に実行できるかどうかをチェックする。このチェックは、アクセス権チェックを含んでよく、プリミティブのフォーマットが適正であるかをチェックし、かつ所定の時間で実行が実施可能であるかをチェックする。

図７のステップ３（成功）では、チェックが成功した場合、ＣＳＥ７０４、７０６および７０８は、＜ｔｒａｎｓａｃｔｉｏｎ＞リソースが生成されて、＜ｔｒａｎｓａｃｔｉｏｎ＞リソースの親リソースが予約状態になっていることをＡＥ７０２に応答する。予約状態では、リソースは、特定の実行時間でのプリミティブの正常実行に障害をもたらす可能性のある他のいずれのリクエストも拒否する。

図７のステップ４（成功）では、各ＣＳＥ７０４、７０６および７０８は、特定の実行時間に対応するプリミティブを実行する。

図８のステップ３（失敗）では、ＣＳＥでのいずれか（この例では、ＣＳＥ７０８）でチェックが失敗した場合は、ＣＳＥ７０８は、失敗応答でＡＥに応答する。失敗応答を受信した場合、ＡＥ７０２は、全てのＣＳＥにわたってトランザクションが原子的に実施できないと判断する。そのため、ＡＥ７０２は、＜ｔｒａｎｓａｃｔｉｏｎ＞リソースを正常に生成した各ＣＳＥ（この例では、ＣＳＥ７０４および７０６）に削除リクエストを送信し、スケジュールされた実行時間前に＜ｔｒａｎｓａｃｔｉｏｎ＞リソースを削除する。これによりトランザクションがキャンセルされる。

図８のステップ４（失敗）では、＜ｔｒａｎｓａｃｔｉｏｎ＞を正常に生成したＣＳＥ（この例では、ＣＳＥ７０４および７０６）は、トランザクションを削除する。

以下のユースケースは、Ｍ２Ｍ／ＩｏＴネットワークにおけるトランザクション処理性能の必要性を理解する上で有用である。複数のロボット９０４、９０６および９０８を備える図９の製造組立ライン９０２などのスマートファクトリーユースケースを考察する。これらのロボット９０４、９０６および９０８は、組立ラインによって製造される製品を適切に組み立てるために互いに緊密な同期を維持する必要がある。ロボットの設定のうち１つを修正する場合、通常、ロボットが互いに同調した操作を続けるよう、同じ組立ラインで動作している他のロボットに対しても対応する修正を要する。工場内の全ての組立ラインは、工場のコントロール室に位置する対応する遠隔管理ステーションから、技術者によって監視および制御されている。それぞれの組立ラインのロボットは、これらのステーションから、技術者によって遠隔的に監視および制御することができる。ロボットのメンテナンスを実施するために組立ラインを停止すると著しく費用がかかるので、工場では、停止時間を最小限に抑え、さらに組立ライン稼働中にメンテナンスを実施する方法も模索している。このため、技術者は、ロボットの設定変更を厳密に調整して行う性能を望んでいる。また、技術者は、組立ラインのロボットの動作が特定の正常範囲を逸脱したという検出に基づいてこれらの更新をトリガする性能も望んでいる。これが発生した場合、ロボット９０４、９０６および９０８の設定の構成に対する更新をトリガし、状況が悪化する前に修復することを技術者は望んでいる。そのためには、トリガイベントに基づいてロボットの設定を変更する分散トランザクションを送信する性能が必要である。また、ロボットが同調する動作を維持したまま、組立ラインが停止することなく機能を続行するよう、このトランザクションで複数のロボット９０４、９０６および９０８の設定を原子的に更新させる必要がある。そうすることで、技術者は、全てのロボットが設定を正常に変更できる場合にのみ、ロボット９０４、９０６および９０８の設定が変更されることが保証される。１つまたは複数のロボットが、それらの設定を正常に変更できない場合は、いずれのロボットの設定も変更されない。これにより、組立ラインにおいてロボットが同調して動作しなくなった状態になることを回避できる。技術者は、ロボットに対するこれらの原子的なトランザクションの管理を調整するために複雑なアプリケーションを開発するのではなく、こうしたＩｏＴサービスプラットフォームのトランザクション管理性能の複雑性が軽減されることを望んでいる。

現在までのところ、分散リソースのセットを対象とする原子的なトランザクションを実施することの複雑性および負担は、これらのトランザクションを開始するアプリケーション、および、これらのアプリケーションを構築して導入する開発者の肩に直接的にかかっている。膨大な数の分散デバイスを含む最近のＩｏＴネットワーク展開の大きさと複雑性の増大によって、これらのアプリケーションおよび開発者に与えるこの負担はさらに大きくなっている。このため、最近では、ｏｎｅＭ２ＭなどのＩｏＴ／Ｍ２Ｍサービス層技術により、分散トランザクションの管理によってアプリケーションを支援する必要性が認識されている。

これまでに、分散サービス層トランザクション（ＤＳＬＴ）の管理のために、極めて基本的かつ最小限のＳＬ中心ソリューションのみが規定されている。例えば、ｏｎｅＭ２Ｍ[oneM2M TR-0020]にて規定されている現行のソリューションは、ＤＳＬＴを管理するために、依然としてアプリケーションに大きく依存している。アプリケーションの役割は、依然として、ＤＳＬＴを構成する個々のリクエストのそれぞれを開始し、個々のターゲットリソースにこれらのリクエストを送信することである。アプリケーションの役割は、依然として、これらの個々のリクエストのそれぞれの進行状況を監視し、それらのいずれかが失敗になるかどうか、およびＤＳＬＴ全体を中止する必要があるかどうかを判断することである。ＤＳＬＴを中止する必要がある場合、アプリケーションは、キャンセルリクエストを送信する必要があるターゲットを追跡しなければならない。アプリケーションの役割は、さらに、ＤＳＬＴの実行時間を追跡し、ＤＳＬＴを構成する個々のリクエストが、実行時間が経過する前に全てキャンセルされるように、このタイマーが満了する前にこれらのキャンセルリクエストの送信が行われることを確実にすることである。したがって、図１０に示すように、ＤＳＬＴを管理するアプリケーションには、大幅なオーバーヘッドおよび負担が依然として存在する。

図１０のステップ１では、アプリケーション１００２は、複数のデバイス１００４、１００６および１００８にトランザクションリクエストを送信する。

図１０のステップ２では、デバイス１００４、１００６および１００８は、トランザクションを正常に実行できるかどうかチェックする。

図１０のステップ３では、デバイス１００４、１００６および１００８は、アプリケーション１００２に応答して、トランザクションを実行できるがどうかを示す。この例では、デバイス１００８はトランザクションを実行することができない。

図１０のステップ４では、デバイスの１つ（デバイス１００８）がトランザクションの実行ができないので、その他のデバイス（デバイス１００４および１００６）でのトランザクションが中止される。

本明細書では、ＤＳＬＴの処理をそれら自体で管理しなければならないというアプリケーションの複雑さおよび負担を軽減するために、ＤＳＬＴ処理性能をサポートする分散サービス層トランザクション（ＤＳＬＴ）サービスを説明する。ＤＳＬＴ処理性能は、アプリケーションに代わってＤＳＬＴの原子的処理を管理するＤＳＬＴサービス性能と、アプリケーションに代わってＤＳＬＴシーケンスの原子的処理を管理するＤＳＬＴサービス性能と、ＤＳＬＴまたはＤＳＬＴシーケンスを構成する個々のリクエストのスケジューリングを調整するＤＳＬＴサービス性能と、ＤＳＬＴまたはＤＳＬＴシーケンスの実行基準をアプリケーションが定義できるようにするＤＳＬＴサービス性能と、ＤＳＬＴまたはＤＳＬＴシーケンスの再伝送ポリシーをアプリケーションが定義できるようにするＤＳＬＴサービス性能と、ＤＳＬＴまたはＤＳＬＴシーケンスの完了基準をアプリケーションが定義できるようにするＤＳＬＴサービス性能と、ＤＳＬＴまたはＤＳＬＴシーケンスの優先順位をアプリケーションが定義できるようにするＤＳＬＴサービス性能と、ＤＳＬＴまたはＤＳＬＴシーケンスを開始するためのシンプルなＲＥＳＴｆｕｌ ＡＰＩをアプリケーションに提供するＤＳＬＴサービス性能とを含んでよい。

アプリケーションに代わってＤＳＬＴの原子的処理を管理するＤＳＬＴサービス性能に関しては、サービスは、それ自体が分散可能であり、別々のネットワークノードでホストされる複数のサービス層エンティティにわたって展開可能であるＤＳＬＴ管理機能およびＤＳＬＴクライアント機能で構成されてよい。ＤＳＬＴを開始し、かつＤＳＬＴの処理完了時のサービスからの応答を受信するために、アプリケーションは単一のリクエストをサービスに送信するだけでよい。サービスは、アプリケーションが個々のＤＳＬＴターゲットのいずれかと通信すること、またはそのライフサイクルを通してＤＳＬＴを管理することを必要としなくてもよい。サービスは、処理ステータスを提供するために使用されるＤＳＬＴの処理中にＤＳＬＴの状態を保持し、障害が発生する場合にはＤＳＬＴのロールバックを可能にすることができる。サービスは、障害が発生した場合に、ＤＳＬＴの原子性要件を満たすことができるよう個々のリクエストのロールバックおよび中止を実施できるように、ＤＳＬＴに関連付けられた個々のリクエストの分散したセットの正常な配布および実行を管理してよい。

アプリケーションに代わってＤＳＬＴシーケンスの原子的処理を管理するＤＳＬＴサービス性能に関しては、ＤＳＬＴシーケンスは、アプリケーションに代わって、サービスによって原子的に順序付けられ、実施することができるＤＳＬＴのセットで構成されてよい。サービスは、障害が発生した場合に、シーケンスの原子性要件を満たすことができるようシーケンスのロールバックおよび中止を実施することができるように、ＤＳＬＴシーケンスの正常な実行を管理してよい。

設定可能なＤＳＬＴポリシーエンジンをサポートするＤＳＬＴサービス性能に関しては、ポリシーエンジンは、プログラム可能なＤＳＬＴポリシーのセットによって設定されてよい。ポリシーエンジンは、スケジューリングポリシー、再試行ポリシー、優先順位付けポリシー、実行基準ポリシー、完了基準ポリシー、およびシーケンスポリシーなどのＤＳＬＴポリシーをサポートしてもよい。ＤＳＬＴポリシーは、サービスがＤＳＬＴをどう処理するかを制御するルールを定義してもよい。

アプリケーションの要件を満たし、ＤＳＬＴターゲット（例えば、間欠的なネットワークコネクティビティのみを有するＩｏＴデバイス）の要件も満たすタイムウィンドウで実施されるよう、ＤＳＬＴまたはＤＳＬＴのシーケンスを構成する個々のリクエストのスケジューリングを調整するＤＳＬＴサービス性能に関しては、サービスは、ＤＳＬＴがそのターゲットデバイスの全てに対して正常に実施され、ＤＳＬＴの原子的な実行要件を満たすことができるようにＤＳＬＴのターゲットであるＩｏＴデバイスに到達可能なスケジュールを調整して、必要とされるデバイスの全てがオンラインおよび利用可能であることを保証するように支援してよい。サービスは、同じリソースを対象とする複数のＤＳＬＴまたはＤＳＬＴシーケンスが同時に実行しないことを保証してもよいが、それは、それらのターゲットリソースのロックを各々が取得し、それらの対応するトランザクションが独立的かつ互いに干渉しないように実施されることを保証しなければならないためである。

ＤＳＬＴまたはＤＳＬＴシーケンスの実行基準をアプリケーションが定義できるようにするＤＳＬＴサービス性能に関しては、実行基準は、ＤＳＬＴの実行を行うに適している時を判断してトリガするために、サービスによって使用されてよい。実行基準は、１つまたは複数の規定されたＳＬ属性またはメタデータの閾値／値、１つまたは複数のデバイスの状態または１つまたは複数のリソース状態などの過去および現在の状況の解析に基づくＳＬ定義済みイベント、アプリケーションまたはサードパーティのサービスまたは下位ネットワークからＳＬが受信または検出する外部トリガ要件、もしくは別のＳＬトランザクションの正常な完了を含んでもよい。

ＤＳＬＴまたはＤＳＬＴシーケンスの再伝送ポリシーをアプリケーションが定義できるようにするＤＳＬＴサービス性能に関しては、再伝送ポリシーは、ＤＳＬＴの実行の失敗により、サービスのＤＳＬＴ再試行を行うに適している時を判断するために、サービスによって使用されてよい。

ＤＳＬＴまたはＤＳＬＴシーケンスの完了基準をアプリケーションが定義できるようにするＤＳＬＴサービス性能に関しては、完了基準は、ＤＳＬＴを構成する個々のリクエスト結果をもとに、ＤＳＬＴの実行が成功した時または成功しなかった時を判断するために、サービスによって使用されてよい。例えば、正常な完了は、一定のタイムウィンドウ内での完了を要件とし得る。または、一部のＤＳＬＴは、リクエストのサブセットが正常に完了することのみを要件とし得るが、その他のＤＳＬＴは、リクエストの全てが正常であることを要件とし得る。

ＤＳＬＴまたはＤＳＬＴシーケンスの優先順位をアプリケーションが定義できるようにするＤＳＬＴサービス性能に関しては、優先順位は、ＤＳＬＴを相互に順位付けし、必要な場合（例えば、ＤＳＬＴが同じターゲットを共有し、それらの実行をシリアル化する必要がある場合）は、この順位付けに基づいてそれらの実行を順序付けするために、サービスによって使用されてよい。

ＤＳＬＴまたはＤＳＬＴシーケンスを開始するためのシンプルなＲＥＳＴｆｕｌ ＡＰＩをアプリケーションに提供するＤＳＬＴサービス性能に関しては、ＡＰＩはＤＳＬＴごとにＳＬトランザクション識別子を定義することができる。ＡＰＩはＤＳＬＴシーケンスにＳＬシーケンス識別子を定義してもよい。また、ＡＰＩは、アプリケーションからの非ブロッキングリクエスト性能をサポートして、ＤＳＬＴまたはＤＳＬＴシーケンスを開始し、ＤＳＬＴまたはＤＳＬＴシーケンスのステータスを参照し、もしくはＤＳＬＴまたはＤＳＬＴシーケンスを中止することができる。

図１１は、開示されるＤＳＬＴサービスによって達成され得る複雑性の低減をアプリケーションの観点から示す図である。

図１１のステップ１では、アプリケーション１００２は、サーバ１１０２にトランザクションのリクエストを送信する。サーバ１１０２は、ＤＳＬＴサービスを具備しているサービス層を備えるＩｏＴサーバ１１０２であってもよい。サーバ１１０２は、トランザクションの管理を担う。（図１０で行われているように）アプリケーション１００２からサーバ１１０２にトランザクションの管理を移行することによって、アプリケーション１００２での操作を簡略化することができる。

図１１のステップ２では、サーバ１１０２は、複数のデバイス１００４、１００６および１００８にＤＳＬＴリクエストを配布する。

図１１のステップ３では、デバイス１００４、１００６および１００８は、トランザクションを正常に実行できるかどうかチェックする。

図１１のステップ４では、デバイス１００４、１００６および１００８は、サーバに応答して、トランザクションを実行できるかどうかを示す。この例では、デバイスの１つ（デバイス１００８）は、トランザクションを実行することができない。

図１１のステップ５では、デバイスの１つ（デバイス１００８）がトランザクションを実行することができないので、その他のデバイス（デバイス１００４および１００６）でのトランザクションが中止される。

図１１のステップ６では、サーバ１１０２はアプリケーション１００２に応答を送信する。

図１１を図１０と比較すると、ＤＳＬＴを管理するＩｏＴアプリケーション１００２のオーバーヘッドおよび複雑性が大幅に低減されている。記載されるＤＳＬＴサービスを用いることで、ＩｏＴアプリケーション１００２は単一のリクエストと応答でＤＳＬＴを実施できるが、既存のソリューションでは、各トランザクションの状態を管理するためにより多くのメッセージおよび内部ロジックが必要である。

開示されるＤＳＬＴサービスの詳細については以下に記載する。

（ＤＳＬＴアーキテクチャ）
一実施形態では、ＤＳＬＴサービスは、分散サービス層トランザクショントリガ機能（ＤＳＬＴ－ＴＦ）１２０２、分散サービス層トランザクション管理機能（ＤＳＬＴ－ＭＦ）１２０４および１２０６、ならびに分散サービス層トランザクションクライアント機能（ＤＳＬＴ－ＣＦ）１２０８、１２１０、１２１２および１２１４を含んでよい。

ＤＳＬＴ－ＴＦ１２０２を使用して、ＤＳＬＴ－ＭＦ１２０４へのＤＳＬＴトリガリクエスト（ＤＳＬＴ－ＴＲＩＧＧＥＲ）１２１６を開始してよく、これにより、ＤＳＬＴ－ＭＦ１２０４はＤＳＬＴ－ＲＥＱ１２１８を配布および管理してよい。ＤＳＬＴ－ＴＦ１２０２は、軽量かつ薄型の機能であり、ＩｏＴサーバ、ＩｏＴゲートウェイ、ＩｏＴデバイス、およびＩｏＴアプリケーションなどの様々な種類のネットワークノードでホストされてよい。

ＤＳＬＴ－ＭＦ１２０４（および１２０６）は、サービスとして実装されてよい。サービスは独立したサービスであるか、あるいはＩｏＴサービス層のサブサービスとして実装されるかのいずれかであってよい。ＤＳＬＴ－ＭＦサービス１２０４は、ＩｏＴサーバ、ＩｏＴゲートウェイ、ＩｏＴデバイスなどの様々な種類のネットワークノードでホストされてよい。ＤＳＬＴ－ＭＦサービス１２０４は、分散しているＤＳＬＴ－ＣＦのセットへのＤＳＬＴの配布および処理をトリガするリクエストを受信してよい。ＤＳＬＴ－ＭＦ１２０４によって受信される各ＤＳＬＴ－ＴＲＩＧＧＥＲは、１つまたは複数のターゲットを対象とする１つまたは複数のＳＬ操作で構成されてよい。ＤＳＬＴ－ＭＦ１２０４は、その関連するＳＬリクエストの全てを原子的に処理することによってＤＳＬＴ－ＴＲＩＧＧＥＲ１２１６を処理する。必要であれば、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＴＲＩＧＧＥＲ１２１６によって規定されたＳＬリクエストが分散しているＳＬエンティティのセットに正確に配布され、ターゲットＳＬエンティティの全てによって正常に実行されるか、または失敗した場合には、それらのいずれによっても実行されないことを保証する。明確にするため、ＤＳＬＴ－ＭＦ１２０４からＤＳＬＴ－ＣＦ１２０８および１２１０へと配布されるＤＳＬＴリクエストは、ＤＳＬＴ－ＲＥＱ１２１８と呼ぶ。

ＤＳＬＴ－ＣＦ１２１０は、ターゲットとして機能し、ＤＳＬＴ－ＭＦ１２０４から受信する配布されたＤＳＬＴ－ＲＥＱ１２１８を処理する。ＤＳＬＴ－ＣＦ１２０８は、ＩｏＴサーバ、ＩｏＴゲートウェイ、ＩｏＴデバイスおよびＩｏＴアプリケーションなどの様々な種類のネットワークノードでホストされてよい。

例えば、図１２に示すように、ＤＳＬＴ－ＴＦ１２０２をサポートするＩｏＴアプリケーション１２３０は、ＩｏＴサーバ１２３２でホストされているＤＳＬＴ－ＭＦ１２０４にＤＳＬＴ－ＴＲＩＧＧＥＲ１２１６を送信して、ＤＳＬＴ－ＭＦ１２０４に原子的なＤＳＬＴ－ＲＥＱ１２１８および１２１９のセットを配布させ、分散しているＩｏＴデバイス１２３４および１２３６のセット上のアクチュエータ（例えば、電子スイッチ）を更新してもよい。ＤＳＬＴ－ＭＦ１２０４は、各デバイスでホストされているＤＳＬＴ－ＣＦ１２０８および１２１０にＤＳＬＴ－ＲＥＱ１２１８および１２１９を配布してよく、また、それら全てがＤＳＬＴ－ＲＥＱ１２１８および１２１９を正常に実施してそれらのアクチュエータを更新するか、またはそれらのいずれも更新を実施しないことを保証してもよい。そうすることで、全てのデバイスの設定の整合性を維持する。

図１２に示すような、例えば、ＩｏＴゲートウェイならびにＩｏＴデバイス１２３８および１２４０が関与するようなマルチホップシナリオの場合には、ＩｏＴゲートウェイ１２４２のＤＳＬＴ－ＭＦ１２０６を使用して、ＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４から配布されたＤＳＬＴ－ＴＲＩＧＧＥＲ１２２２を受信してよい。そのＤＳＬＴ－ＴＲＩＧＧＥＲがＩｏＴデバイス１２３８および１２４０によってホストされているリソースを対象とすることを検出した場合、ＩｏＴゲートウェイのＤＳＬＴ－ＭＦ１２０６を使用して、ＩｏＴデバイスのＤＳＬＴ－ＣＦ１２１２および１２１４の両方にＤＳＬＴ－ＲＥＱ１２２４および１２２６を配布してもよい。これは、ＤＳＬＴサービスの分散特性、および複数のＤＳＬＴ－ＭＦをどのように使用してシステム全体にわたってＤＳＬＴを原子的に処理するかを示している。

ＤＳＬＴ－ＴＦ１２０２は、ＤＳＬＴ－ＭＦ１２０４へのＤＳＬＴリクエストを開始し、ＤＳＬＴ－ＭＦ１２０４から返信されるＤＳＬＴ応答を受信する性能をサポートしてよいが、他のいずれのＤＳＬＴ処理性能もサポートする必要はない。

ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴを処理するためのいくつかの性能をサポートしてもよい。ＤＳＬＴ－ＭＦの性能のセットを図１３に示す。ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＭＦ ＡＰＩ１３０２、ＤＳＬＴ－ＭＦ処理１３０４、ＤＳＬＴ－ＭＦシーケンス処理１３０６、ＤＳＬＴ－ＭＦポリシーエンジン１３０８およびＤＳＬＴ－ＭＦスケジューラ１３１０を含んでよい。

同様に、ＤＳＬＴ－ＣＦ１２１０は、図１４に示すように、ＤＳＬＴを処理する対応する一連の性能をサポートしてもよい。ＤＳＬＴ－ＣＦ１２１０は、ＤＳＬＴ－ＣＦ ＡＰＩ１４０２、ＤＳＬＴ－ＣＦ処理１４０４およびＤＳＬＴ－ＣＦシーケンス処理１４０６を含んでよい。

以下のサブセクションでは、ＤＳＬＴ－ＭＦ１２０４およびＤＳＬＴ－ＣＦ１２１０のそれぞれの性能のより詳しい定義を提供する。

（ＤＳＬＴ ＡＰＩ）
ＤＳＬＴ－ＭＦ１２０４へのＤＳＬ関連リクエストを開始するためにＤＳＬＴ－ＴＦによって使用され得るＡＰＩ１３０２を、ＤＳＬＴ－ＭＦ１２０４はサポートしてよい。サポートされるリクエストのタイプとしては、新規のＤＳＬＴを開始するタイプ（すなわちＤＳＬＴ－ＴＲＩＧＧＥＲ）、既存のＤＳＬＴのステータスを参照するタイプ（すなわちＤＳＬＴ－ＱＵＥＲＹ）、および未処理のＤＳＬＴを中止するタイプ（ＤＳＬＴ－ＡＢＯＲＴ）を含んでよい。ＡＰＩ１３０２はまた、どのようにＤＳＬＴ－ＭＦがＤＳＬＴを処理し、スケジュールするかを制御するためのルールを定義するポリシーを設定するために使用されてもよい。このＡＰＩ１３０２は、ＤＳＬＴ－ＭＦ１２０４によってホストされているＤＳＬＴ関連メッセージパラメータおよび／またはリソースで構成されるＲＥＳＴｆｕｌインターフェースとしてサポートされてよい。

ＤＳＬＴ－ＣＦ１２１０も同様に、ＡＰＩ１４０２をサポートしてよい。このＡＰＩ１４０２は、ＤＳＬＴ－ＣＦ１２１０にＤＳＬＴ関連リクエストを送信するために、ＤＳＬＴ－ＭＦ１２０４によって使用されてよい。サポートされるリクエストのタイプとしては、新規のＤＳＬＴをＤＳＬＴ－ＣＦ１２１０に転送するタイプ（すなわちＤＳＬＴ－ＲＥＱ）、既存のＤＳＬＴのステータスを参照するタイプ（ＤＳＬＴ－ＱＵＥＲＹ）、およびＤＳＬＴ－ＣＦ１２１０が処理している未処理のＤＳＬＴを中止するタイプ（ＤＳＬＴ－ＡＢＯＲＴ）を含んでよい。このＡＰＩ１４０２は、ＤＳＬＴ－ＣＦ１２１０によってホストされているＤＳＬＴ関連メッセージパラメータおよび／またはリソースで構成されるＲＥＳＴｆｕｌインターフェースとしてサポートされてよい。

（ＤＳＬＴ ＡＰＩリソース）
一実施例では、以下のリソースタイプがＤＳＬＴ－ＭＦ１２０４によってサポートされてよい。

（ＤＳＬＴ ＡＰＩメッセージパラメータ）
ＤＳＬＴメッセージパラメータは、ＤＳＬＴ－ＴＲＩＧＧＥＲ、ＤＳＬＴ－ＳＥＱ－ＴＲＩＧＧＥＲ、ＤＳＬＴ－ＲＥＱ、ＤＳＬＴ－ＱＵＥＲＹおよびＤＳＬＴ－ＡＢＯＲＴなどの様々なタイプのＤＳＬＴメッセージに適用できるものであってよい。これらの種々のＤＳＬＴメッセージタイプは、ＣＲＵＤ操作およびいくつかのＤＳＬＴメッセージパラメータを使用して、各ＤＳＬＴメッセージタイプが実装され得るＲＥＳＴｆｕｌ ＡＰＩにマップされてよい。

単一のＤＳＬＴリクエストに加えて、ＤＳＬＴシーケンスを形成するために２つまたはそれ以上のＤＳＬＴが組み合わされてもよい。ＤＳＬＴシーケンスは、ＤＳＬＴの順序付けリストを規定する。複数のＤＳＬＴは、単一のＳＬリクエスト内で一緒にまとめて処理されるか、あるいはＤＳＬＴシーケンスは、同じ値を有するＤＳＬＴシーケンス識別子を使用して互いに関連付けられてもよい。ＤＳＬＴ－ＭＦ１２０４ならびにＤＳＬＴ－ＣＦ１２１０および１２０８は協働して、ＤＳＬＴシーケンスを原子的に処理および実行してよい。処理は、個々のＤＳＬＴの原子的な実行および全シーケンスの原子的な処理を含む。したがって、個々のＤＳＬＴのいずれかが正常に完了しない場合は、ＤＳＬＴシーケンスによって対象とされるいずれのリソースも、ＤＳＬＴシーケンスの実行開始前と同じ元の状態に戻されるように、ＤＳＬＴ－ＭＦ１２０４ならびにＤＳＬＴ－ＣＦ１２１０および１２０８は、シーケンス内の全てのＤＳＬＴのロールバックをサポートしてよい。

以下は、ＤＳＬＴシーケンスに関連するメッセージパラメータのセットである。

（ＤＳＬＴ ＡＰＩ識別子）
個々のＤＳＬＴのＳＬ識別子を表７に示す。ＤＳＬＴシーケンスの識別子を表６に示す。これらのＤＳＬＴ識別子の構成は、表５に示すような複数のコンポーネントで構成されてよい。識別子は、サービスプロバイダコンポーネント（ＳＰ－ＩＤ）、ＤＳＬＴ－ＭＦコンポーネント（ＤＳＬＴ－ＭＦ－ＩＤ）、ＤＳＬＴシーケンスコンポーネント（ＤＳＬＴ－ＳＥＱ－ＩＤ）、ＤＳＬＴコンポーネント（ＤＳＬＴ－ＩＤ）およびＳＬリクエストＩＤコンポーネント（ＳＬ－ＲＥＱ－ＩＤ）で構成されてよい。

ＤＳＬＴがシステム内のどこで使用されるかによって、異なるフォーマットと一意性要件が存在してもよい。例えば、ＤＳＬＴが、ＤＳＬＴ－ＭＦ１２０４がホストされているのと同じＩｏＴサービスプロバイダドメイン内でホストされているＤＳＬＴ－ＣＦを対象とするためだけに使用される場合、ＤＳＬＴ識別子の一意性要件はＳＰ－ＩＤコンポーネントを必要としなくてもよい。一方で、ＤＳＬＴが、ＤＳＬＴ－ＭＦ１２０４とは異なるＩｏＴサービスプロバイダドメイン内でホストされているＤＳＬＴ－ＣＦを対象としている場合、ＤＳＬＴは、ＳＬインスタンス全体にわたっておよびサービスプロバイダドメイン全体にわたって一意であり、かつＳＰ－ＩＤを含む識別子を必要としてもよい。

（ＤＳＬＴ処理性能）
個々のＤＳＬＴの処理方法およびＤＳＬＴシーケンスの処理方法について以下で説明する。これらの方法のそれぞれは、ＤＳＬＴ－ＴＦ１２０２、ＤＳＬＴ－ＭＦ１２０４およびＤＳＬＴ－ＣＦ１２１０によって実施される動作を有する。それぞれの動作は、以下の説明で明確にされる。

（個々のＤＳＬＴ処理）
個々のＤＳＬＴは、ＤＳＬＴ－ＭＦ１２０４にＤＳＬＴ－ＴＲＩＧＧＥＲリクエスト１２１６を送信することで、ＤＳＬＴ－ＴＦ１２０２によって開始される１つのＤＳＬＴで構成されてよい。次に、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＴＲＩＧＧＥＲリクエスト１２１６を処理する。この処理では、ＤＳＬＴ－ＭＦ１２０４が、ＤＳＬＴのターゲットである分散しているＳＬエンティティのセットに、複数のＤＳＬＴ－ＲＥＱ１２１８および１２１９を配布する。ＤＳＬＴ－ＲＥＱを受信する各ＳＬエンティティは、ＤＳＬＴ－ＲＥＱを処理することができるＤＳＬＴ－ＣＦ１２０８および１２１０をホストしている。ＤＳＬＴ－ＭＦ１２０４は、配布したＤＳＬＴ－ＲＥＱ１２１９および１２１８のセットを管理し、それらが原子的に処理されることを保証する。完了すると、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＴＲＩＧＧＥＲリクエスト１２１６を発信したＤＳＬＴ－ＴＦ１２０２に応答を返す。この応答は、ＤＳＬＴの結果を含む。

個々のＤＳＬＴを処理する方法全体は、ＤＳＬＴを開始するＤＳＬＴ－ＴＦ１２０２、ＤＳＬＴの処理を管理するＤＳＬＴ－ＭＦ１２０４、およびＤＳＬＴを規定した操作をターゲットリソースで実施するＤＳＬＴ－ＣＦ１２０８および１２１０、で構成される３つの好適な方法に細分することが可能である。これらの各方法の説明を、以下のフロー図に記載する。

図１５は、個々のＤＳＬＴに対するＤＳＬＴ－ＴＦの処理を示す図である。

図１５のステップ１では、ＤＳＬＴ－ＴＦ１２０２をホストしているＳＬエンティティ（例えば、アプリケーション）１２３０においてＤＳＬＴのトリガ要件（例えば、アプリケーション固有イベント）が発生する。

図１５のステップ２では、ＤＳＬＴ－ＴＦ１２０２はＤＳＬＴ－ＴＲＩＧＧＥＲリクエストを生成し、ＤＳＬＴ－ＭＦ１２０４をホストしているＳＬエンティティに、該リクエストを送信する。これにより、ＤＳＬＴ－ＭＦ１２０４は、ＳＬエンティティの代わりにＤＳＬＴ処理を実施できる。ＤＳＬＴ－ＴＦ１２０２は、ＤＳＬＴ－ＭＦ１２０４がＤＳＬＴ処理の完了を示す応答を返してくるのを待つ。

図１５のステップ３ａでは、ＤＳＬＴ－ＭＦ１２０４はＤＳＬＴ－ＴＦ１２０２に、ＤＳＬＴ処理が完了したことを応答し、この処理のステータスを含める。

図１５のステップ３ｂでは、ＤＳＬＴ－ＴＦ１２０２はＤＳＬＴ－ＭＦ１２０４からの応答を待ってタイムアウトする。ＤＳＬＴ－ＴＦ１２０２は、ＤＳＬＴ－ＭＦ１２０４にＤＳＬＴ－ＴＲＩＧＧＥＲを再送信することによってＤＳＬＴを再試行する。

図１５のステップ３ｃでは、ＤＳＬＴ－ＴＦ１２０２はＤＳＬＴリクエストの中止を決定する。この決定は、ＤＳＬＴ－ＴＦ１２０２が再試行を望まないと決定した後のタイムアウトに起因するものであってもよい。または、この決定は、アプリケーション固有の理由などの他の要因に基づくものであってもよい。

図１５のステップ４では、ＤＳＬＴ－ＴＦ１２０２は、ＤＳＬＴ－ＭＦ１２０４によって返されたＤＳＬＴの結果をチェックする。

図１５のステップ５ａでは、ＤＳＬＴは、ＤＳＬＴ－ＭＦ１２０４によって正常に処理された。ＤＳＬＴ－ＴＦ１２０２は、ＤＳＬＴが完了したとみなしてよい。

図１５のステップ５ｂでは、ＤＳＬＴは正常に処理されなかった。ＤＳＬＴ－ＴＦ１２０２は、ＤＳＬＴ－ＭＦ１２０４にＤＳＬＴの処理を再試行させるために、ＤＳＬＴ－ＭＦ１２０４にＤＳＬＴ－ＴＲＩＧＧＥＲリクエストを再発行することによるＤＳＬＴの再試行を決定する。

図１５のステップ５ｃでは、ＤＳＬＴは正常に処理されなかった。ＤＳＬＴ－ＴＦ１２０２は、再試行ではなく、ＤＳＬＴリクエストの中止を決定する。

図１５のステップ６では、ＤＳＬＴが正常に処理されて、ＤＳＬＴ－ＴＦ１２０２は、ＤＳＬＴトリガリクエストを起動したエンティティ（例えば、アプリケーション）にその結果を返す。

図１５のステップ７では、ＤＳＬＴ－ＴＦはＤＳＬＴの中止を決定した。ＤＳＬＴ－ＴＦ１２０２が、ＤＳＬＴ－ＭＦ１２０４から応答を受信したか否かによって、ＤＳＬＴ－ＴＦ１２０２は、ＤＳＬＴの中止を決定したことを通知するために、ＤＳＬＴ－ＭＦ１２０４に中止リクエストを送信することを決定してよい。

図１６は、個々のＤＳＬＴに対するＤＳＬＴ－ＭＦ１２０４の処理を示す図である。

図１６のステップ１では、ＤＳＬＴ－ＴＦ１２０２をホストしているＳＬエンティティは、ＤＳＬＴ－ＭＦ１２０４をホストしているＳＬエンティティに、ＤＳＬＴ－ＴＲＩＧＧＥＲリクエストを送信して、ＤＳＬＴを開始する。

図１６のステップ２では、ＤＳＬＴ－ＭＦ１２０４は、リクエストを処理し、ＤＳＬＴ－ＴＲＩＧＧＥＲによって対象とされているＤＳＬＴ－ＣＦ１２０８および１２１０のそれぞれに、ＤＳＬＴ－ＲＥＱを配布する。ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＣＦ１２０８および１２１０のそれぞれから、ターゲットリソースのロックを正常に取得したことを示す応答を待つ。

図１６のステップ３ａでは、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＣＦ１２０８および１２１０の全て（または定義された完了基準に応じたサブセット）がターゲットリソースのロックを正常に取得できたことを検出する。

図１６のステップ３ｂでは、ＤＳＬＴ－ＭＦ１２０４は、１つまたは複数のＤＳＬＴ－ＣＦ１２０８および１２１０からの応答を待ってタイムアウトする。ＤＳＬＴ－ＭＦ１２０４は、タイムアウトした１つまたは複数のＤＳＬＴ－ＣＦに、ＤＳＬＴ－ＲＥＱを再送信することによってＤＳＬＴを再試行する。

図１６のステップ３ｃでは、ＤＳＬＴ－ＭＦ１２０４はＤＳＬＴリクエストの中止を決定する。この決定は、ＤＳＬＴ－ＭＦ１２０４が（例えば、再試行の最大数に到達して）再試行を望まないと決定した後のタイムアウトに起因するものであってよい。１つまたは複数のＤＳＬＴ－ＣＦがターゲットリソースのロックを正常に取得できなかったことを、ＤＳＬＴ－ＭＦ１２０４が検知する場合、ＤＳＬＴ－ＭＦ１２０４は、全てのターゲットＤＳＬＴ－ＣＦ１２０８および１２１０にわたってＤＳＬＴを原子的に実施することができないので、ＤＳＬＴの（定義された完了基準に応じて）中止を選択してもよい。ＤＳＬＴ－ＭＦ１２０４は、各ＤＳＬＴ－ＣＦに実行コマンドを送信しないことを選択して、ＤＳＬＴをタイムアウトさせることによってＤＳＬＴを中止するか、または各ＤＳＬＴ－ＣＦに中止コマンドを明確に送信してよい。中止の決定は、１つまたは複数のＤＳＬＴ－ＣＦが到達可能でないなどの他の要因にも基づいてよい。

図１６のステップ４では、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＣＦに実行コマンドを送信することによってＤＳＬＴによって規定された操作を実行するようにＤＳＬＴ－ＣＦ１２０８および１２１０に命令する。ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＣＦのそれぞれから、ターゲットリソースで操作を正常に実行したことを示す応答を待つ。

図１６のステップ５ａでは、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＣＦの全て（または定義された完了基準に応じたサブセット）がターゲットリソースでＤＳＬＴによって規定された操作を正常に実行できたことを検出する。

図１６のステップ５ｂでは、ＤＳＬＴ－ＭＦ１２０４は、１つまたは複数のＤＳＬＴ－ＣＦ１２０８および１２１０からの応答を待ってタイムアウトする。ＤＳＬＴ－ＭＦ１２０４は、タイムアウトした１つまたは複数のＤＳＬＴ－ＣＦへの実行コマンドの送信を再試行する。

図１６のステップ５ｃでは、ＤＳＬＴ－ＭＦ１２０４はＤＳＬＴリクエストの中止を決定する。この決定は、ＤＳＬＴ－ＭＦ１２０４が（例えば、再実行の最大数に到達して）再試行を望まないと決定した後のタイムアウトに起因するものであってよい。または、この決定は、１つまたは複数のＤＳＬＴ－ＣＦが到達可能でないなどの他の要因に基づくものであってよい。ＤＳＬＴ－ＭＦ１２０４が、１つまたは複数のＤＳＬＴ－ＣＦがターゲットリソースで操作を正常に実行できなかったことを検出した場合、ＤＳＬＴ－ＭＦ１２０４は、全てのターゲットＤＳＬＴ－ＣＦ１２０８および１２１０にわたってＤＳＬＴを原子的に実施することができないので、ＤＳＬＴの（定義された完了基準に応じて）中止を選択してもよい。ＤＳＬＴ－ＭＦ１２０４は、各ＤＳＬＴ－ＣＦ１２０８および１２１０に実行コマンドを送信しないことを選択して、ＤＳＬＴをタイムアウトさせることによってＤＳＬＴを中止するか、または各ＤＳＬＴ－ＣＦ１２０８および１２１０に中止コマンドを明確に送信してよい。

図１６のステップ６では、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴによって規定された操作をコミットするようにＤＳＬＴ－ＣＦ１２０８および１２１０に命令する。ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＣＦ１２０８および１２１０のそれぞれから、ターゲットリソースで操作を正常にコミットしたことを示す応答を待つ。

図１６のステップ７ａでは、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＣＦ１２０８および１２１０の全て（または定義された完了基準に応じたサブセット）がターゲットリソースでＤＳＬＴによって規定された操作の結果を正常にコミットできたことを検出する。

図１６のステップ７ｂでは、ＤＳＬＴ－ＭＦ１２０４は、１つまたは複数のＤＳＬＴ－ＣＦ１２０８および１２１０からの応答を待ってタイムアウトする。ＤＳＬＴ－ＭＦ１２０４は、タイムアウトした１つまたは複数のＤＳＬＴ－ＣＦ１２０８および１２１０へのコミットコマンドの送信を再試行する。

図１６のステップ７ｃでは、ＤＳＬＴ－ＭＦ１２０４はＤＳＬＴリクエストの中止を決定する。この決定は、ＤＳＬＴ－ＭＦ１２０４が（例えば、再実行の最大数に到達して）再実行を望まないと決定した後のタイムアウトに起因するものであってよい。または、この決定は、１つまたは複数のＤＳＬＴ－ＣＦ１２０８および１２１０が到達可能ではないなどの他の要因に基づくものであってよい。

図１６のステップ８では、ＤＳＬＴが正常に処理されて、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴをトリガしたＤＳＬＴ－ＴＦ１２０２に、その結果を返す。

図１６のステップ９では、ＤＳＬＴ－ＭＦはＤＳＬＴの中止を決定した。ＤＳＬＴ－ＭＦ１２０４が、ＤＳＬＴ－ＣＦ１２０８および１２１０から応答を受信したか否かによって、ＤＳＬＴ－ＭＦ１２０４は、１つまたは複数のＤＳＬＴ－ＣＦ１２０８および１２１０に明確な中止リクエストを送信することを決定し、ＤＳＬＴの中止を決定したことを１つまたは複数のＤＳＬＴ－ＣＦ１２０８および１２１０に通知してもよい。これにより、１つまたは複数のＤＳＬＴ－ＣＦ１２０８および１２１０は、ＤＳＬＴの処理を停止するプロセス、ターゲットリソースの状態を元の状態にロールバックするプロセス、またはターゲットリソースをアンロックするプロセスなど、任意の必要なプロセスを実施してもよい。

図１７は、個々のＤＳＬＴ－ＣＦに対するＤＳＬＴ－ＣＦの処理を示す。

図１７のステップ１では、ＤＳＬＴ－ＣＦ１２１０をホストしているＳＬエンティティは、ＤＳＬＴ－ＭＦ１２０４からＤＳＬＴ－ＲＥＱを受信する。

図１７のステップ２では、ＤＳＬＴ－ＣＦ１２１０がリクエストリソースのロックを試みる初期化処理ステップである。

図１７のステップ３ａでは、ＤＳＬＴ－ＣＦ１２１０は、ＤＳＬＴ－ＲＥＱによって対象とされるリソースのロックを（必要に応じて）正常に取得することができる。ロックリソースの状態がコミットされてアンロックされるまでロックリソースの取得もブロックされなければならない場合があるので、このブロッキングは、他のＤＳＬＴ－ＲＥＱからの全ての操作に適用され得る。

図１７のステップ３ｂでは、ＤＳＬＴ－ＣＦ１２１０は、タイムアウト期間が経過する前にターゲットリソースのロックを取得することができず、その後、ＤＳＬＴ－ＣＦ１２１０はタイムアウトを選択し、ＤＳＬＴ－ＲＥＱを中止する。ＤＳＬＴ－ＣＦ１２１０は、ＤＳＬＴ－ＭＦ１２０４にこのタイムアウトを通知してよい。タイムアウト後、ＤＳＬＴ－ＣＦ１２１０は、ＤＳＬＴ－ＭＦ１２０４から再試行されたＤＳＬＴ－ＲＥＱを受信してもよく、この場合、ＤＳＬＴ－ＣＦ１２１０は、ステップ１からフローを繰り返してよい。

図１７のステップ３ｃでは、ＤＳＬＴ－ＣＦ１２１０は、明確な中止コマンドをＤＳＬＴ－ＭＦ１２０４から受信し、その後、ＤＳＬＴ－ＣＦ１２１０はＤＳＬＴ－ＲＥＱを中止する。ＤＳＬＴ－ＣＦ１２１０がいずれかのターゲットリソースのロックを取得できていた場合、ＤＳＬＴ－ＣＦ１２１０は、これらのロックを解放し、ＤＳＬＴの処理を停止する。ＤＳＬＴ－ＣＦは、ＤＳＬＴ－ＭＦ１２０４から再試行されたＤＳＬＴ－ＲＥＱを受信してもよく、この場合、ＤＳＬＴ－ＣＦは、ステップ１からフローを繰り返してよい。

図１７のステップ４では、ターゲットリソースのロックが、（必要に応じて）各ＤＳＬＴ－ＣＦによって取得される。各ＤＳＬＴ－ＣＦは、ロックが取得されたか、またはロックが必要でないことをＤＳＬＴ－ＭＦ１２０４に通知する。ＤＳＬＴ－ＣＦ１２１０は、ターゲットリソースでＤＳＬＴ規定操作を実行するコマンドをＤＳＬＴ－ＭＦ１２０４から受信するまでこの状態で待つ。

図１７のステップ５ａでは、ＤＳＬＴ－ＣＦ１２１０は、ＤＳＬＴ－ＭＦ１２０４から実行コマンド受信して、ターゲットリソースでＤＳＬＴ規定操作の実行を正常に完了することができた。

図１７のステップ５ｂでは、ＤＳＬＴ－ＣＦ１２１０は、タイムアウト期間が経過する前にＤＳＬＴ－ＭＦ１２０４から実行コマンドを受信せず、その後、ＤＳＬＴ－ＣＦ１２１０はＤＳＬＴ－ＲＥＱをタイムアウトし、リソースをアンロックする。ＤＳＬＴ－ＣＦ１２１０は、ＤＳＬＴ－ＭＦ１２０４にこのタイムアウトを通知してよい。タイムアウト後、ＤＳＬＴ－ＣＦ１２１０はＤＳＬＴ－ＭＦ１２０４からＤＳＬＴ－ＲＥＱコマンドを受信してよい。

図１７のステップ５ｃでは、ＤＳＬＴ－ＣＦ１２１０はＤＳＬＴ－ＲＥＱの実行を中止する。これは、ＤＳＬＴ－ＭＦ１２０４から実行コマンドを受信し、ターゲットリソースでＤＳＬＴ規定操作を正常に実行できないことに起因するものであってよい。あるいは、これは、ＤＳＬＴ－ＣＦ１２１０がＤＳＬＴ－ＭＦ１２０４から中止コマンドを受信することに起因するものであってもよい。

図１７のステップ６では、ＤＳＬＴ－ＣＦ１２１０は実行を正常に完了した。ＤＳＬＴは、ＤＳＬＴ－ＭＦ１２０４にその実行ステータスを通知し、ＤＳＬＴ－ＭＦ１２０４からのコミットコマンドを待つ。

図１７のステップ７ａでは、ＤＳＬＴ－ＣＦ１２１０は、ＤＳＬＴ－ＭＦ１２０４からコミットコマンドを受信して、ターゲットリソースの状態を正常にコミットできたため、結果が耐久的に維持される。

図１７のステップ７ｂでは、ＤＳＬＴ－ＣＦ１２１０は、タイムアウト期間が経過する前にＤＳＬＴ－ＭＦ１２０４からコミットコマンドを受信せず、その後、ＤＳＬＴ－ＣＦ１２１０はＤＳＬＴ－ＲＥＱをタイムアウトする。ＤＳＬＴ－ＣＦ１２１０は、他のＤＳＬＴ－ＣＦと整合した状態を維持するために中止するのではなく、更新されたリソースの状態を引き続きコミットする。ＤＳＬＴ－ＣＦ１２１０は、リソースのアンロックも行う。

図１７のステップ７ｃでは、ＤＳＬＴ－ＣＦ１２１０はＤＳＬＴ－ＲＥＱのコミットを中止する。これは、ＤＳＬＴ－ＭＦ１２０４からコミットコマンドを受信し、結果を正常にコミットできないことに起因するものであってよい。あるいは、これは、ＤＳＬＴ－ＣＦ１２１０がＤＳＬＴ－ＭＦ１２０４から中止コマンドを受信することに起因するものであってもよい。

図１７のステップ８では、コミット後、ＤＳＬＴ－ＣＦ１２１０はＤＳＬＴによって対象とされたリソースのロックを解放してよい。この場合、ＤＳＬＴ－ＣＦ１２１０は、ＤＳＬＴ－ＭＦ１２０４にコミットの通知を送信してもよい。

図１７のステップ９では、ＤＳＬＴ－ＣＦ１２１０は、ＤＳＬＴの中止およびロールバックを行い、ＤＳＬＴ－ＭＦ１２０４に、対応するステータスを返す。中止後、ＤＳＬＴ－ＣＦはリソースのロックを解放する必要がある。この場合、ＤＳＬＴ－ＣＦ１２１０は、ＤＳＬＴ－ＭＦ１２０４に中止の通知を送信してもよい。

（ＤＳＬＴシーケンス処理）
ＤＳＬＴシーケンスは、原子的な順序付けられたセットとして処理される必要がある複数の分散サービス層トランザクションで構成される。ＤＳＬＴシーケンスは、ＤＳＬＴ－ＭＦ１２０４にＤＳＬＴ－ＳＥＱ－ＴＲＩＧＧＥＲリクエストを送信するＤＳＬＴ－ＴＦ１２０２によってトリガされる。次に、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴシーケンスを処理する。この処理では、ＤＳＬＴ－ＭＦ１２０４が、ＤＳＬＴシーケンスのターゲットである分散しているＳＬエンティティのセットにＤＳＬＴ－ＲＥＱを配布する。ＤＳＬＴ－ＲＥＱを受信する各ＳＬエンティティは、ＤＳＬＴ－ＲＥＱを処理することができるＤＳＬＴ－ＣＦ１２０８および１２１０をホストしている。ＤＳＬＴ－ＭＦ１２０４は、シーケンス内のＤＳＬＴ－ＲＥＱの全てが原子的に順序付けられて処理されることを保証する。完了すると、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＳＥＱ－ＴＲＩＧＧＥＲリクエストを発信したＤＳＬＴ－ＴＦ１２０２に応答を返す。この応答は、ＤＳＬＴシーケンスの結果を含む。

ＤＳＬＴシーケンスを処理する方法全体は、ＤＳＬＴシーケンスを開始するＤＳＬＴ－ＴＦ１２０２、ＤＳＬＴシーケンスの処理を管理するＤＳＬＴ－ＭＦ１２０４、およびシーケンス内の個々のＤＳＬＴによって規定された操作をターゲットリソースで実施するＤＳＬＴ－ＣＦ１２０８および１２１０、で構成される３つの好適な方法に細分することが可能である。これらの各方法の説明を、以下のフロー図に記載する。

図１８は、ＤＳＬＴシーケンスに対するＤＳＬＴ－ＴＦ１２０２の処理を示す図である。

図１８のステップ１では、ＤＳＬＴ－ＴＦ１２０２をホストしているＳＬエンティティ（例えば、アプリケーション）においてＤＳＬＴシーケンストリガ要件（例えば、アプリケーション固有イベント）が発生する。

図１８のステップ２では、ＤＳＬＴ－ＴＦ１２０２はＤＳＬＴ－ＳＥＱ－ＴＲＩＧＧＥＲリクエストを生成し、ＤＳＬＴ－ＭＦ１２０４をホストしているＳＬエンティティに、該リクエストを送信する。これにより、ＤＳＬＴ－ＭＦ１２０４は、ＳＬエンティティの代わりにＤＳＬＴシーケンス処理を実施できる。ＤＳＬＴ－ＴＦ１２０２は、ＤＳＬＴ－ＭＦ１２０４がＤＳＬＴシーケンス処理の完了を示す応答を返してくるのを待つ。

図１８のステップ３ａでは、ＤＳＬＴ－ＭＦ１２０４はＤＳＬＴ－ＴＦ１２０２に、ＤＳＬＴシーケンス処理が完了したことを応答し、この処理のステータスを含める。

図１８のステップ３ｂでは、ＤＳＬＴ－ＴＦ１２０２はＤＳＬＴ－ＭＦ１２０４からの応答を待ってタイムアウトする。ＤＳＬＴ－ＴＦ１２０２は、ＤＳＬＴ－ＭＦ１２０４にＤＳＬＴ－ＳＥＱ－ＴＲＩＧＧＥＲリクエストを再送信することによってＤＳＬＴシーケンスを再試行する。

図１８のステップ３ｃでは、ＤＳＬＴ－ＴＦ１２０２はＤＳＬＴ－ＳＥＱ－ＴＲＩＧＧＥＲリクエストの中止を決定する。この決定は、ＤＳＬＴ－ＴＦ１２０２が再試行を望まないと決定した後のタイムアウトに起因するものであってもよい。または、この決定は、アプリケーション固有の理由などの他の要因に基づくものであってもよい。

図１８のステップ４では、ＤＳＬＴ－ＴＦ１２０２は、ＤＳＬＴ－ＭＦ１２０４によって返されたＤＳＬＴシーケンスの結果をチェックする。

図１８のステップ５ａでは、ＤＳＬＴシーケンスは、ＤＳＬＴ－ＭＦ１２０４によって正常に処理された。ＤＳＬＴ－ＴＦ１２０２は、ＤＳＬＴシーケンスが完了したとみなしてよい。

図１８のステップ５ｂでは、ＤＳＬＴシーケンスは正常に処理されなかった。ＤＳＬＴ－ＴＦ１２０２は、ＤＳＬＴ－ＭＦ１２０４にＤＳＬＴの処理を再試行させるために、ＤＳＬＴ－ＭＦ１２０４にＤＳＬＴ－ＳＥＱ－ＴＲＩＧＧＥＲリクエストを再発行することによるＤＳＬＴシーケンスの再試行を決定する。

図１８のステップ５ｃでは、ＤＳＬＴシーケンスは正常に処理されなかった。ＤＳＬＴ－ＴＦ１２０２は、再試行ではなく、ＤＳＬＴシーケンスリクエストの中止を決定する。

図１８のステップ６では、ＤＳＬＴシーケンスが正常に処理されて、ＤＳＬＴ－ＴＦ１２０２は、ＤＳＬＴシーケンストリガリクエストを起動したエンティティ（例えば、アプリケーション）にその結果を返す。

図１８のステップ７では、ＤＳＬＴ－ＴＦ１２０２はＤＳＬＴシーケンスの中止を決定した。ＤＳＬＴ－ＴＦ１２０２が、ＤＳＬＴ－ＭＦ１２０４から応答を受信したか否かによって、ＤＳＬＴ－ＴＦ１２０２は、ＤＳＬＴシーケンスの中止を決定したことを通知するために、ＤＳＬＴ－ＭＦ１２０４に中止リクエストを送信することを決定してよい。

図１９は、ＤＳＬＴシーケンスに対するＤＳＬＴ－ＭＦ１２０４の処理を示す図である。

図１９のステップ１では、ＤＳＬＴ－ＴＦ１２０２をホストしているＳＬエンティティは、ＤＳＬＴ－ＭＦ１２０４をホストしているＳＬエンティティに、ＤＳＬＴ－ＳＥＱ－ＴＲＩＧＧＥＲリクエストを送信して、ＤＳＬＴシーケンスを開始する。

図１９のステップ２では、ＤＳＬＴ－ＭＦ１２０４は、リクエストを処理し、ＤＳＬＴ－ＴＲＩＧＧＥＲによって対象とされているＤＳＬＴ－ＣＦ１２０８および１２１０のそれぞれに、シーケンス内の最初のＤＳＬＴに対応するＤＳＬＴ－ＲＥＱを配布する。ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＣＦ１２０８および１２１０のそれぞれから、ターゲットリソースのロックを正常に取得したことを示す応答を待つ。

図１９のステップ３ａでは、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＣＦ１２０８および１２１０の全て（または定義された完了基準に応じたサブセット）がターゲットリソースのロックを正常に取得できたことを検出する。

図１９のステップ３ｂでは、ＤＳＬＴ－ＭＦ１２０４は、１つまたは複数のＤＳＬＴ－ＣＦ１２０８および１２１０からの応答を待ってタイムアウトする。ＤＳＬＴ－ＭＦ１２０４は、タイムアウトした１つまたは複数のＤＳＬＴ－ＣＦに、シーケンス内の最初のＤＳＬＴに対応するＤＳＬＴ－ＲＥＱを再送信することによってＤＳＬＴを再試行する。

図１９のステップ３ｃでは、ＤＳＬＴ－ＭＦ１２０４は、シーケンス完了基準に応じて、シーケンス内の最初のＤＳＬＴリクエスト、および場合によっては全てのＤＳＬＴシーケンスの中止を決定する。この決定は、ＤＳＬＴ－ＭＦ１２０４が（例えば、再実行の最大数に到達して）再試行を望まないと決定した後のタイムアウトに起因するものであってよい。１つまたは複数のＤＳＬＴ－ＣＦがターゲットリソースのロックを正常に取得できなかったことをＤＳＬＴ－ＭＦ１２０４が検知した場合、ＤＳＬＴ－ＭＦ１２０４は、全てのターゲットＤＳＬＴ－ＣＦ１２０８および１２１０にわたってＤＳＬＴを原子的に実施することができないので、（定義された完了基準に応じて）ＤＳＬＴの中止を選択してもよい。ＤＳＬＴ－ＭＦ１２０４は、各ＤＳＬＴ－ＣＦ１２０８および１２１０に実行コマンドを送信しないことを選択して、ＤＳＬＴをタイムアウトさせることによってＤＳＬＴを中止するか、または各ＤＳＬＴ－ＣＦ１２０８および１２１０に中止コマンドを明確に送信してもよい。中止の決定は、１つまたは複数のＤＳＬＴ－ＣＦが到達可能でないなどの他の要因にも基づいてよい。

図１９のステップ４では、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＣＦ１２０８および１２１０に実行コマンドを送信することによって、シーケンス内の最初のＤＳＬＴによって規定された操作を実行するようにＤＳＬＴ－ＣＦ１２０８および１２１０に命令する。ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＣＦ１２０８および１２１０のそれぞれから、ターゲットリソースで操作を正常に実行したことを示す応答を待つ。

図１９のステップ５ａでは、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＣＦ１２０８および１２１０の全て（または定義された完了基準に応じたサブセット）がターゲットリソースでＤＳＬＴによって規定された操作を正常に実行できたことを検出する。

図１９のステップ５ｂでは、ＤＳＬＴ－ＭＦ１２０４は、１つまたは複数のＤＳＬＴ－ＣＦ１２０８および１２１０からの応答を待ってタイムアウトする。ＤＳＬＴ－ＭＦ１２０４は、タイムアウトした１つまたは複数のＤＳＬＴ－ＣＦへの実行コマンドの送信を再試行する。

図１９のステップ５ｃでは、ＤＳＬＴ－ＭＦ１２０４は、シーケンス完了基準に応じて、シーケンス内の最初のＤＳＬＴリクエスト、および場合によっては全てのＤＳＬＴシーケンスの中止を決定する。この決定は、ＤＳＬＴ－ＭＦ１２０４が（例えば、再実行の最大数に到達して）再実行を望まないと決定した後のタイムアウトに起因するものであってよい。または、この決定は、１つまたは複数のＤＳＬＴ－ＣＦ１２０８および１２１０が到達可能ではないなどの他の要因に基づくものであってもよい。１つまたは複数のＤＳＬＴ－ＣＦがターゲットリソースで操作を正常に実行できなかったことをＤＳＬＴ－ＭＦ１２０４が検出する場合、ＤＳＬＴ－ＭＦ１２０４は、全てのターゲットＤＳＬＴ－ＣＦ１２０８および１２１０にわたってＤＳＬＴを原子的に実施することができないので、（定義された完了基準に応じて）ＤＳＬＴの中止を選択してもよい。ＤＳＬＴ－ＭＦ１２０４は、各ＤＳＬＴ－ＣＦ１２０８および１２１０に実行コマンドを送信しないことを選択して、ＤＳＬＴをタイムアウトさせることによってＤＳＬＴを中止するか、または各ＤＳＬＴ－ＣＦ１２０８および１２１０に中止コマンドを明確に送信してもよい。

図１９のステップ６では、ステップ２で記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。

図１９のステップ７ａでは、ステップ３ａで記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。

図１９のステップ７ｂでは、ステップ３ｂで記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。

図１９のステップ７ｃでは、ステップ３ｃで記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。

図１９のステップ８では、ステップ４で記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。

図１９のステップ９ａでは、ステップ５ａで記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。

図１９のステップ９ｂでは、ステップ５ｂで記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。

図１９のステップ９ｃでは、ステップ５ｃで記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。

図１９のステップ１０では、ステップ２で記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。

図１９のステップ１１ａでは、ステップ３ａで記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。

図１９のステップ１１ｂでは、ステップ３ｂで記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。

図１９のステップ１１ｃでは、ステップ３ｃで記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。

図１９のステップ１２では、ステップ４で記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。

図１９のステップ１３ａでは、ステップ５ａで記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。

図１９のステップ１３ｂでは、ステップ５ｂで記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。

図１９のステップ１３ｃでは、ステップ５ｃで記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。

図１９のステップ１４では、ＤＳＬＴ－ＭＦ１２０４が、ＤＳＬＴ－ＣＦ１２０８および１２１０の全て（または定義されたシーケンス完了基準に応じたサブセット）が、ＤＳＬＴの全シーケンスによって規定されているように、全ターゲットリソースで操作を全て正常に実行できたことを検知する場合、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＣＦ１２０８および１２１０のそれぞれに、結果の状態を耐久的に維持するように、シーケンス内の該当する全てのＤＳＬＴのコミットを命令する。

図１９のステップ１５ａでは、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＣＦ１２０８および１２１０の全て（または定義された完了基準に応じたサブセット）がターゲットリソースでＤＳＬＴによって規定された操作の結果を正常にコミットできたことを検出する。

図１９のステップ１５ｂでは、ＤＳＬＴ－ＭＦ１２０４は、１つまたは複数のＤＳＬＴ－ＣＦからの応答を待ってタイムアウトする。ＤＳＬＴ－ＭＦ１２０４は、タイムアウトした１つまたは複数のＤＳＬＴ－ＣＦへのコミットコマンドの送信を再試行する。

図１９のステップ１５ｃでは、ＤＳＬＴ－ＭＦ１２０４は、シーケンス完了基準に基づいてＤＳＬＴシーケンスの中止を決定する。この決定は、ＤＳＬＴ－ＭＦ１２０４が（例えば、再試行の最大数に到達して）再試行を望まないと決定するタイムアウトに起因するものであってよい。または、この決定は、１つまたは複数のＤＳＬＴ－ＣＦが到達可能でないなどの他の要因に基づくものであってもよい。ＤＳＬＴ－ＭＦ１２０４が、１つまたは複数のＤＳＬＴ－ＣＦがターゲットリソースで操作を正常にコミットできなかったことを検出した場合、ＤＳＬＴ－ＭＦ１２０４は、全てのターゲットＤＳＬＴ－ＣＦ１２０８および１２１０にわたってＤＳＬＴシーケンスを原子的に実施することができないので、（定義された完了基準に応じて）ＤＳＬＴシーケンスの中止を選択してもよい。ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴシーケンスをトリガしたＤＳＬＴ－ＴＦ１２０２にエラーを返すことによってＤＳＬＴシーケンスを中止してよい。

図１９のステップ１６では、ＤＳＬＴシーケンスが正常に処理されて、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴシーケンスをトリガしたＤＳＬＴ－ＴＦ１２０２に、その結果を返す。

図１９のステップ１７では、ＤＳＬＴ－ＭＦはＤＳＬＴシーケンスの中止を決定した。ＤＳＬＴ－ＭＦ１２０４が、ＤＳＬＴ－ＣＦ１２０８および１２１０から応答を受信したか否かによって、ＤＳＬＴ－ＭＦ１２０４は、１つまたは複数のＤＳＬＴ－ＣＦ１２０８および１２１０に明確な中止リクエストを送信することを決定し、シーケンス内の１つまたは複数のＤＳＬＴの中止を決定したことを１つまたは複数のＤＳＬＴ－ＣＦ１２０８および１２１０に通知してもよい。これにより、１つまたは複数のＤＳＬＴ－ＣＦ１２０８および１２１０は、ＤＳＬＴシーケンスの処理を停止するプロセス、ターゲットリソースの状態を元の状態にロールバックするプロセス、またはターゲットリソースをアンロックするプロセスなど、任意の必要なプロセスを実施してもよい。

図２０は、ＤＳＬＴシーケンスに対するＤＳＬＴ－ＣＦの処理を示す図である。

図２０のステップ１では、ＤＳＬＴ－ＣＦ１２１０をホストしているＳＬエンティティは、ＤＳＬＴ－ＭＦ１２０４からシーケンス内の最初のＤＳＬＴに対応するＤＳＬＴ－ＲＥＱを受信する。あるいは、各ＤＳＬＴ－ＣＦ１２０８および１２１０は、単一のリクエストで一緒にまとめて処理されるシーケンス内の全てのＤＳＬＴを受信してもよい。

図２０のステップ２では、ＤＳＬＴ－ＣＦ１２１０はＤＳＬＴ－ＲＥＱを処理し、トランザクションが他のいずれのＤＳＬＴ－ＲＥＱからも独立し、かつ干渉されずに実施されることを保障するために、ＤＳＬＴ－ＲＥＱによって対象とされるリソースのロックを（必要に応じて）試みる。ＤＳＬＴ－ＣＦ１２１０は、（必要に応じて）ロックが取得されるまでこの状態で待つ。ＤＳＬＴ－ＣＦ１２１０は、このロックをＤＳＬＴシーケンスに関連付けて、同じシーケンス内の各ＤＳＬＴ（その他のいずれのＤＳＬＴでもない）がリソースで動作することを可能にしてよい。このロックは、操作の種類によって左右されるものであってよい。例えば、操作が更新または削除である場合のみ、ターゲットリソースをロックする。しかし、一部のユースケースでは、取得を実施するＤＳＬＴ－ＲＥＱが実行される前に、別のＤＳＬＴ－ＲＥＱがリソースを変更または削除しないことを確実にするために、取得のためのロックも保証されてもよい。一旦、リソースが１つのＤＳＬＴ－ＲＥＱによってロックされると、このロックを使用して、他のＤＳＬＴ－ＲＥＱが該リソースにアクセスすることをブロックしてよい。ロックリソースの状態がコミットされてアンロックされるまでロックリソースの取得もブロックされる必要があり得るため、このブロッキングは、他のＤＳＬＴ－ＲＥＱからの全ての操作に適用できるものであってよい。

図２０のステップ３ａでは、ＤＳＬＴ－ＣＦ１２１０は、ＤＳＬＴ－ＲＥＱによって対象とされるリソースのロックを（必要に応じて）正常に取得することができる。ロックリソースの状態がコミットされてアンロックされるまでロックリソースの取得もブロックされる必要があり得るため、このブロッキングは、他のＤＳＬＴ－ＲＥＱからの全ての操作に適用できるものであってよい。

図２０のステップ３ｂでは、ＤＳＬＴ－ＣＦ１２１０は、タイムアウト期間が経過する前にターゲットリソースのロックを取得することができず、その後、ＤＳＬＴ－ＣＦ１２１０はタイムアウトしてＤＳＬＴ－ＲＥＱを中止することを選択する。ＤＳＬＴ－ＣＦ１２１０は、ＤＳＬＴ－ＭＦ１２０４にこのタイムアウトを通知してよい。タイムアウト後、ＤＳＬＴ－ＣＦは、ＤＳＬＴ－ＭＦ１２０４から再試行されたＤＳＬＴ－ＲＥＱを受信してもよく、この場合、ＤＳＬＴ－ＣＦは、ステップ１からフローを繰り返してよい。

図２０のステップ３ｃでは、ＤＳＬＴ－ＣＦ１２１０は、明確な中止コマンドをＤＳＬＴ－ＭＦ１２０４から受信し、その後、ＤＳＬＴ－ＣＦ１２１０はＤＳＬＴ－ＲＥＱを中止する。ＤＳＬＴ－ＣＦ１２１０がいずれかのターゲットリソースロックを取得することができていた場合、ＤＳＬＴ－ＣＦ１２１０は、これらのロックを解放し、ＤＳＬＴの処理を停止する。ＤＳＬＴ－ＣＦ１２１０は、ＤＳＬＴ－ＭＦ１２０４から再試行されたＤＳＬＴ－ＲＥＱを受信してもよく、この場合、ＤＳＬＴ－ＣＦ１２１０は、ステップ１からフローを繰り返してよい。

図２０のステップ４では、ターゲットリソースのロックが、各ＤＳＬＴ－ＣＦ１２０８および１２１０によって（必要に応じて）取得される。各ＤＳＬＴ－ＣＦは、ＤＳＬＴ－ＭＦ１２０４に、ロックが取得されたか、またはロックが必要でないことを通知する。ＤＳＬＴ－ＣＦは、ＤＳＬＴ－ＭＦ１２０４からターゲットリソースでＤＳＬＴ規定操作を実行するコマンドを受信するまでこの状態で待つ。

図２０のステップ５ａでは、ＤＳＬＴ－ＣＦ１２１０は、ＤＳＬＴ－ＭＦ１２０４から実行コマンドを受信して、ターゲットリソースでＤＳＬＴ規定操作の実行を正常に完了することができた。

図２０のステップ５ｂでは、ＤＳＬＴ－ＣＦ１２１０は、タイムアウト期間が経過する前にＤＳＬＴ－ＭＦ１２０４から実行コマンドを受信せず、その後、ＤＳＬＴ－ＣＦ１２１０はＤＳＬＴ－ＲＥＱをタイムアウトし、リソースをアンロックする。ＤＳＬＴ－ＣＦ１２１０は、ＤＳＬＴ－ＭＦ１２０４にこのタイムアウトを通知してよい。タイムアウト後、ＤＳＬＴ－ＣＦ１２１０はＤＳＬＴ－ＭＦ１２０４からＤＳＬＴ－ＲＥＱコマンドを受信してよい。

図２０のステップ５ｃでは、ＤＳＬＴ－ＣＦ１２１０はＤＳＬＴ－ＲＥＱの実行を中止する。これは、ＤＳＬＴ－ＭＦ１２０４から実行コマンドを受信し、ターゲットリソースでＤＳＬＴ規定操作を正常に実行できないことに起因するものであってよい。あるいは、これは、ＤＳＬＴ－ＣＦ１２１０がＤＳＬＴ－ＭＦ１２０４から中止コマンドを受信することに起因するものであってもよい。

図２０のステップ６では、ＤＳＬＴ－ＣＦ１２１０は実行を正常に完了した。ＤＳＬＴ－ＣＦ１２１０は、ＤＳＬＴ－ＭＦ１２０４にその実行ステータスを通知し、シーケンス内の次のＤＳＬＴ、またはＤＳＬＴ－ＭＦ１２０４からのコミットコマンドを待つ。次のＤＳＬＴがシーケンス中に受信される場合、ステップ２で記載したのと同じ動作が、該次のＤＳＬＴの処理に適用されてよい。

図２０のステップ７ａでは、ステップ３ａで記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。

図２０のステップ７ｂでは、ステップ３ｂで記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。

図２０のステップ７ｃでは、ステップ３ｃで記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。

図２０のステップ８では、ステップ４で記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。

図２０のステップ９ａでは、ステップ５ａで記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。

図２０のステップ９ｂでは、ステップ５ｂで記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。

図２０のステップ９ｃでは、ステップ５ｃで記載したのと同じ動作が、２番目のＤＳＬＴの処理に適用されてよい。

図２０のステップ１０では、ステップ６で記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。

図２０のステップ１１ａでは、ステップ３ａで記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。

図２０のステップ１１ｂでは、ステップ３ｂで記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。

図２０のステップ１１ｃでは、ステップ３ｃで記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。

図２０のステップ１２では、ステップ４で記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。

図２０のステップ１３ａでは、ステップ５ａで記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。

図２０のステップ１３ｂでは、ステップ５ｂで記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。

図２０のステップ１３ｃでは、ステップ５ｃで記載したのと同じ動作が、Ｎ番目のＤＳＬＴの処理に適用されてよい。

図２０のステップ１４では、ＤＳＬＴ－ＣＦ１２１０は、シーケンス内のＮ番目のＤＳＬＴの実行を正常に完了する。ＤＳＬＴ－ＣＦ１２１０は、ＤＳＬＴ－ＭＦ１２０４にその実行ステータスを通知し、シーケンス内の次のＤＳＬＴ、またはＤＳＬＴ－ＭＦ１２０４からのコミットコマンドを待つ。

図２０のステップ１５ａでは、ＤＳＬＴ－ＣＦ１２１０は、シーケンス内のＤＳＬＴを正常にコミットすることができた。

図２０のステップ１５ｂでは、ＤＳＬＴ－ＣＦ１２１０は、タイムアウト期間が経過する前に、シーケンス内で次に続くＤＳＬＴ、またはＤＳＬＴ－ＭＦ１２０４からのコミットコマンドを受信せず、その後、ＤＳＬＴ－ＣＦ１２１０はＤＳＬＴシーケンスをタイムアウトする。これが起こった場合／起こったとき、ＤＳＬＴ－ＣＦは、シーケンス内の更新されたリソースの状態をコミットせずに中止する。これにより、ターゲットリソースの状態は、シーケンス内のいずれのＤＳＬＴ操作も実施される前の初期状態にロールバックされる。同様に、ターゲットリソースでＤＳＬＴ規定操作を実施した後に、ＤＳＬＴ－ＣＦ１２１０がＤＳＬＴ－ＭＦ１２０４から明確な中止コマンドを受信する場合、ＤＳＬＴ－ＣＦ１２１０は、更新されたリソースの状態をコミットせずにＤＳＬＴシーケンスを中止することによってＤＳＬＴシーケンスを中止してよい。これにより、ターゲットリソースの状態は、シーケンス内のいずれのＤＳＬＴ操作も実施される前の初期状態にロールバックされる。ＤＳＬＴ－ＣＦ１２１０は、ＤＳＬＴ－ＭＦ１２０４にこの中止を通知してよい。

図２０のステップ１５ｃでは、ＤＳＬＴ－ＣＦ１２１０は、シーケンスの一部として処理され、まだコミットされていない全てのＤＳＬＴのコミットを中止する。これは、ＤＳＬＴ－ＭＦ１２０４からコミットコマンドを受信し、結果を正常にコミットできないことに起因するものであってよい。あるいは、これは、ＤＳＬＴ－ＣＦ１２１０がＤＳＬＴ－ＭＦ１２０４から中止コマンドを受信することに起因するものであってもよい。

図２０のステップ１６では、コミット後、ＤＳＬＴ－ＣＦ１２１０は、シーケンス内のいずれかのＤＳＬＴによって対象とされたリソースのロックを解放してよい。この場合、ＤＳＬＴ－ＣＦは、ＤＳＬＴ－ＭＦ１２０４にコミットの通知を送信してもよい。

図２０のステップ１７では、タイムアウトまたは中止が発生した場合、ＤＳＬＴ－ＣＦは、シーケンスの一部として処理された全てのＤＳＬＴを中止してロールバックし、ＤＳＬＴ－ＭＦ１２０４に対応するステータスを返してよい。中止後、ＤＳＬＴ－ＣＦ１２１０は、同様にリソースのロックを解放する必要がある。この場合、ＤＳＬＴ－ＣＦ１２１０は、ＤＳＬＴ－ＭＦ１２０４に中止の通知を送信してもよい。

（ＤＳＬＴ－ＭＦポリシーエンジン性能）
ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴポリシーエンジン性能１３０８をサポートしてよい。そのＡＰＩによって、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ処理ポリシーを、生成、取得、更新または削除するためのポリシー構成リクエストをサポートしてよい。これらのポリシーを使用して、ＤＳＬＴ－ＭＦ１２０４内部に、ＤＳＬＴの処理の方法、ならびにターゲットＤＳＬＴ－ＣＦ１２０８および１２１０との相互作用を制御するＤＳＬＴ処理ルールを構成してよい。

ＤＳＬＴ処理ポリシーには、以下の種類のものを使用してよい。
・ＤＳＬＴスケジューリングポリシー
ＤＳＬＴ－ＭＦ１２０４が、ＤＳＬＴまたはＤＳＬＴシーケンスの処理をどのようにスケジュールするか制御するルールを設定するために使用されるポリシー。
・ＤＳＬＴ再試行ポリシー
ＤＳＬＴ－ＭＦ１２０４が、処理が失敗したＤＳＬＴまたはＤＳＬＴシーケンスをいつ再試行するか制御するルールを設定するために使用されるポリシー。ルールには、ＤＳＬＴが再試行することができる回数の最大限度または最小限度を含んでよい。
・ＤＳＬＴ優先順位付けポリシー
ＤＳＬＴ－ＭＦ１２０４が、どのようにＤＳＬＴまたはＤＳＬＴシーケンスの処理を互いに対して優先順位付けおよび順位付けするか制御するルールを設定するために使用されるポリシー。
・ＤＳＬＴ実行基準ポリシー
ＤＳＬＴ－ＭＦ１２０４が、どのようにＤＳＬＴまたはＤＳＬＴシーケンスに対して実行基準を割り当てて処理するか制御するルールを設定するために使用されるポリシー。
・ＤＳＬＴ完了基準ポリシー
ＤＳＬＴ－ＭＦ１２０４が、どのようにＤＳＬＴまたはＤＳＬＴシーケンスに対して完了基準を割り当てて処理するか制御するルールを設定するために使用されるポリシー。

上記の種類のポリシーのそれぞれの適用性／範囲が設定されてよい。例えば、ポリシーの範囲は以下のものに限定されてよい。
特定の送信元（例えば、特定のＤＳＬＴ－ＴＦ１２０２または複数のＤＳＬＴ－ＴＦ１２０２のグループ）から発信されるＤＳＬＴ
特定のターゲット（例えば、特定のＤＳＬＴ－ＣＦまたはＤＳＬＴ－ＣＦのグループ）を対象とするＤＳＬＴ
特定のタイプのＤＳＬＴ（例えば、生成と同等の操作でのＤＳＬＴ）

以下の種類のポリシーエンジン機能が使用されてよい。ＤＳＬＴ－ＭＦ１２０４は、受信する受信ＤＳＬＴリクエストに、対応するポリシールール（例えば、スケジューリング、再試行、優先順位付け、および完了基準ルール）を適用してもよい。これらのルールは、これらのパラメータに対して、明確にその対応する値を定義していない（例えば、これらの値を明確に定めるＤＳＬＴメッセージパラメータを含まない）ＤＳＬＴリクエストに適用することができるデフォルトとして使用されてよい。ＤＳＬＴリクエストがこれらのパラメータのうちの１つまたは複数に対する明確な値を含まない場合、これらのポリシーは限度として使用されてよい。ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴリクエストにおいて明確に定義されたパラメータに対してこれらのポリシー限度を比較してもよく、必要に応じて、限度に従うように明確な値を変更することによってこれらの限度に実効性をもたせる。

（リソース予約のためのＤＳＬＴ－ＭＦスケジューリング性能）
ＤＳＬＴ－ＭＦ１２０４は、集約化型ＤＳＬＴスケジューリング機能１３１０として機能してもよい。ＤＳＬＴ－ＭＦ１２０４は、分散しているＳＬエンティティのセットへのアクセス、およびＤＳＬＴを実行するために必要とされる該分散している各ＳＬエンティティによってホストされているリソースへのアクセスの、スケジューリング性能をサポートしてよい。あらかじめこのスケジューリングを先回りして行うことによって、所定のＤＳＬＴを実行するのに必要なリソースが必要に応じて利用可能になり、これらのリソースに対する競合が最小限に抑えられることを保証する支援をしてもよい。これにより、最初の試みでＤＳＬＴ処理が成功する可能性が高くなる場合があり、性能が向上（例えば、再試行の試みの発生を低減）する場合がある。集約化型ＤＳＬＴ－ＭＦスケジューリング性能は、ターゲットリソースおよびＤＳＬＴのそれぞれで規定された対応する操作を検査してもよい。全ＤＳＬＴにわたる情報のこの集約セットに基づいて、ＤＳＬＴ－ＭＦ１２０４は、得られた情報からＤＳＬＴスケジューリングを決定し、未処理の全ＤＳＬＴの上位集合にわたって対象とされるリソースへのアクセスを最適化する。

以下のＤＳＬＴスケジューリング機能１３１０が使用されてよい。
（１）ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴがそのターゲットデバイスの全てに対して正常に実施され、ＤＳＬＴの原子的な実行要件を満たすことができるようにＤＳＬＴのターゲットであるＩｏＴデバイスの到達可能スケジュールを調整して、全ての必要とされるデバイスがオンラインおよび利用可能であることを保証するように支援してよい。デバイスのうち１つが利用できない場合、原子性欠如によってＤＳＬＴが失敗することになるので、これは重大である。ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴリクエストがターゲットデバイスに対して発行される前に、ターゲットデバイス同士が互いに連携するように、ターゲットデバイスのそれぞれを調整して、それらのコネクティビティスケジュールを構成してよい。この連携は、本質的に反復性であるタイプのＤＳＬＴに、ワンタイム／アドホックベースで行われるか、繰り返し／継続ベースで行われてよい。
（２）ＤＳＬＴ－ＭＦ１２０４は、同じリソースを対象とする複数のＤＳＬＴまたはＤＳＬＴシーケンスが同時に実行しないことを保証してもよいが、それは、それらのターゲットリソースのロックを各々が取得し、独立的に、かつ互いに干渉しないようにそれらの対応するトランザクションを実施することを保証する必要があるためである。同じリソースを対象とする複数のＤＳＬＴの同時実行を試みると、最適でないＤＳＬＴ実行（例えば、遅延、タイムアウト、再試行など）またはＤＳＬＴの失敗をももたらす場合がある。ＤＳＬＴ－ＭＦ１２０４は、各ＤＳＬＴおよびその構成ターゲットを検査してよい。次いで、ターゲットが重複しているそれらＤＳＬＴは同時に実行されず、ターゲットが重複していないＤＳＬＴは重複してもよいことを保証するために、各ＤＳＬＴの実行を互いに対して適切にスケジュールして、順序付けしてよい。ＤＳＬＴ－ＭＦ１２０４は、各ＤＳＬＴ内で構成される優先順位を考慮にいれて、これをそのスケジューリングアルゴリズムに含んで、低優先順位ＤＳＬＴの前に高優先順位ＤＳＬＴを実行できるようにしてよい。

（ＤＳＬＴプロシージャ）
以下のプロシージャでは、正常なＤＳＬＴ処理シナリオについて記載する。

（個々のＤＳＬＴ処理）
図２１は、個々のＤＳＬＴプロシージャを示す図である。

図２１のステップ１は、任意のステップである。図２１のステップ１では、ＩｏＴアプリケーションのＤＳＬＴ－ＴＦ１２０２がＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４にＤＳＬＴポリシーリソースを生成するようにリクエストを送信する。各ポリシーリソースは、ＤＳＬＴ－ＭＦ１２０４がＤＳＬＴリクエストをどのように処理するかを制御するための１つまたは複数のルールを含んでよい。これらのルールは、ＤＳＬＴスケジューリング、ＤＳＬＴの再試行、ＤＳＬＴの優先順位付け、ＤＳＬＴ向けの実行基準および完了基準に関連してよい。あるいは、ＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴポリシーによって事前にプロビジョンされてもよい。

図２１のステップ２は、任意のステップである。図２１のステップ２では、ＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４は、リクエストを受信して処理し、ＤＳＬＴポリシーリソースを生成する。ＤＳＬＴ－ＭＦ１２０４はポリシーリソースを生成し、さらに、ポリシーで規定されたルールによってそのＤＳＬＴポリシーエンジン１３０８の設定も行う。

図２１のステップ３は、任意のステップである。図２１のステップ３では、ＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４は、ＩｏＴアプリケーションのＤＳＬＴ－ＴＦ１２０２に応答を返して、ポリシーリソースで定義されたルールが受諾されたか否か通知する。受諾されなかった場合、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＭＦ１２０４によって受諾されたルールの修正バージョンを提供してよい。

図２１のステップ４では、ＩｏＴアプリケーションのＤＳＬＴ－ＴＦ１２０２がＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４にＤＳＬＴ－ＴＲＩＧＧＥＲリクエストを送信する。リクエストは、ターゲットノード（例えば、ＩｏＴデバイス１およびＩｏＴデバイス２）のセット、これらのノードで実施する操作、この操作をいつ実施するかのスケジュール、実行基準のセット、優先順位、トランザクションの処理の試みが失敗した場合の再試行の回数、完了基準のセット、ＤＳＬＴ－ＭＦ１２０４がトランザクションを非ブロッキング式に処理するのに使用してもよいＤＳＬＴ識別子およびコンタクト情報などのいくつかのパラメータを含んでよい。

図２１のステップ５では、ＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＴＲＩＧＧＥＲリクエストを受信して処理を開始する。ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴリクエストリソースを生成して、ＤＳＬＴの処理の間、状態を追跡する。ＤＳＬＴ－ＭＦ１２０４は、ステップ４で示したＤＳＬＴ－ＴＲＩＧＧＥＲリクエストパラメータに含まれた情報を用いてリソースの属性を構成する。

図２１のステップ６では、ＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４は、リクエストを受信して処理を開始したことを示す応答をＩｏＴアプリケーションのＤＳＬＴ－ＴＦ１２０２に返すことによって、ＤＳＬＴ－ＴＲＩＧＧＥＲリクエストを非ブロッキング式に処理する。あるいは、ＤＳＬＴ－ＭＦ１２０４は、このリクエストをブロッキング式に処理してもよい。

図２１のステップ７では、ＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＴＲＩＧＧＥＲリクエストを解析し、対象とされるリソースのリストを見つける。ＤＳＬＴ－ＭＦ１２０４は、ターゲットリソースが、ＩｏＴサーバでローカルにホストされておらず、ＩｏＴデバイス１および２によってホストされていることを検出する。その後、ＤＳＬＴ－ＭＦ１２０４は、これらのターゲットデバイスに配布する対応するＤＳＬＴ－ＲＥＱを準備する。リクエストの配布の前に、ＤＳＬＴ－ＣＦ１２１０はまず、スケジュール情報がＤＳＬＴ－ＴＲＩＧＧＥＲリクエストで、またはいずれかのＤＳＬＴスケジュール関連ポリシー内で明確に構成されたかどうかをチェックする。ＤＳＬＴ－ＭＦ１２０４はまた、ＤＳＬＴ－ＴＲＩＧＧＥＲリクエストまたはいずれかのＤＳＬＴスケジュールポリシーにおいて、いずれかの優先順位が明確に設定されたかどうかをチェックする。明確に設定されていた場合、ＤＳＬＴ－ＭＦ１２０４は、既に受信して、かつ処理の必要があるその他のＤＳＬＴ－ＴＲＩＧＧＥＲリクエストがあるかどうかをチェックする。ある場合、ＤＳＬＴ－ＭＦ１２０４は、優先順位およびスケジュール情報を使用して、ＤＳＬＴ－ＴＲＩＧＧＥＲリクエストの実行を互いに対して順位付けおよび順序付けする。一旦、スケジュールおよび優先順位によって順序付けが行われると、ＤＳＬＴ－ＭＦ１２０４は、それに応じてターゲットにＤＳＬＴ－ＲＥＱを配布する。ＤＳＬＴ－ＭＦ１２０４の優先順位付けポリシーに応じて、処理が進行されているＤＳＬＴ－ＴＲＩＧＧＥＲよりも優先順位が高い新しいＤＳＬＴ－ＴＲＩＧＧＥＲが受信される場合、ＤＳＬＴ－ＭＦ１２０４は、処理が進行されているＤＳＬＴ－ＴＲＩＧＧＥＲを完了するか、または新たに届いた優先順位の高いＤＳＬＴ－ＴＲＩＧＧＥＲを処理するために割り込みしてもよい。割り込みする場合は、ＤＳＬＴ－ＭＦ１２０４は、後で処理を再開するのに有利なように、トランザクションを中止してロールバックするか、またはＤＳＬＴ－ＭＦ１２０４は、優先順位の高いトランザクションを処理している間処理を一時停止し、その後、処理を再開してよい。中止するか割り込みするかの判断は、優先順位の高いトランザクションが、処理が進行されている優先順位の低いものと同じリソースを対象としているかどうかなど、いくつかの要因に基づくものであってよい。この場合、ＤＳＬＴ－ＭＦ１２０４は優先順位の低いトランザクションの中止を決定してよいが、その一方で、２つのトランザクションが異なるリソースを対象としているケースでは、ＤＳＬＴ－ＭＦ１２０４は、優先順位の低いトランザクションへの割り込みを選択するか、またはサポートされている場合は、両方のトランザクションを並行して実行してよい。

図２１のステップ８では、ＩｏＴデバイス１２３４および１２３６のＤＳＬＴ－ＣＦ１２０８および１２１０は、それぞれのＤＳＬＴ－ＲＥＱを受信する。どちらともリクエストを処理し、ローカルＤＳＬＴリソースを生成して、ＤＳＬＴ－ＲＥＱを処理している間、トランザクションの状態を追跡する。ＤＳＬＴ－ＣＦ１２０８および１２１０は、ＤＳＬＴ－ＲＥＱパラメータ内に含まれている情報を用いてそれらのリソースの属性を構成する。ＤＳＬＴ－ＣＦ１２０８および１２１０は、まず、ターゲットリソースの利用可能性をチェックすることからトランザクションの処理を開始する。リソースがＩｏＴデバイスに対してローカルの場合、ＤＳＬＴ－ＣＦ１２１０は、規定操作を実施するためのリソースの利用可能性、ならびに現時点でリソースを予約およびロックしている他のトランザクションがないことをチェックする。リソースが利用可能な場合は、ＤＳＬＴ－ＣＦ１２１０は、現在のトランザクションの処理中に届く可能性のある他のトランザクションからの干渉を受けることなく、該リソースでトランザクションを実施してもよいようにリソースをロックしてよい。ＤＳＬＴ－ＣＦ１２１０がＤＳＬＴ－ＲＥＱを受信して、リクエストがローカルデバイスでホストされていないリソースを対象としていることを見つけた場合、ＤＳＬＴ－ＣＦ（場合によっては、デバイスでホストされているローカルＤＳＬＴ－ＭＦ１２０４と提携している）は、その他のデバイスのＤＳＬＴ－ＣＦ１２１０がそれを処理してもよいように、システム内の別のデバイスに向けてＤＳＬＴ－ＲＥＱリクエストを再度対象としてよい。

図２１のステップ９では、各ＩｏＴデバイスのＤＳＬＴ－ＣＦ１２１０は、ＤＳＬＴ－ＲＥＱが受信されて、トランザクションで処理が開始して、ターゲットリソースが利用可能であり、他のトランザクションから干渉を受けることなく現在のトランザクションが進行できるようにリソースがロックされたことを示すステータスをＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４に返す。

図２１のステップ１０では、全てのターゲットＤＳＬＴ－ＣＦ１２０８および１２１０（すなわち、ＩｏＴデバイス１および２の両方）が、ターゲットリソースを正常にロックしたと応答したことを、ＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４が検出する。その結果、ＤＳＬＴ－ＭＦ１２０４は、トランザクションの実行をするように、ターゲットＤＳＬＴ－ＣＦに続いて命令してよいと判断する。ＤＳＬＴ－ＭＦ１２０４が全てのターゲットから正常なロックの応答を受信しなかった場合、いずれかの完了基準がトランザクションのために構成されているか、またはそのポリシーのいずれかで規定されているかをチェックすることができる。完了基準が規定されている場合、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＭＦ１２０４が手順を進めることが基準によって許容されているかどうかをチェックしてよい（例えば、基準は、全てのターゲットではなく、ターゲットのサブセットのみでトランザクションが完了することが必要とされると規定している場合がある）。あるいは、トランザクションのうちの１つまたは複数がターゲットリソースのロックに失敗した場合、ＤＳＬＴ－ＭＦ１２０４は、トランザクションがその設定パラメータまたはポリシー設定を介して再試行されるよう設定されているか否かチェックしてよい。再試行が許可されている場合、ＤＳＬＴ－ＭＦ１２０４は失敗したトランザクションを再試行してもよい。この場合、ＤＳＬＴ－ＭＦ１２０４は、失敗したＤＳＬＴ－ＣＦに再試行を送信してよい。完了基準を満たすことができず、トランザクションの再試行ができないとＤＳＬＴ－ＭＦ１２０４が判断する場合は、ＤＳＬＴ－ＭＦ１２０４はトランザクションの中止を選択してよい。トランザクションを中止するために、ＤＳＬＴ－ＭＦ１２０４は、トランザクションターゲットのそれぞれ（この例では、ＩｏＴデバイス１２３４および１２３６のＤＳＬＴ－ＣＦ１２０８および１２１０）に中止コマンドを送信する。中止を受信すると、ＤＳＬＴ－ＣＦは、トランザクションによって対象とされたリソースに対して行われたいずれの変更もトランザクションの開始前と同じ状態に戻されるようにロールバックすることによってトランザクションを中止する。ＤＳＬＴ－ＣＦは、ターゲットリソースのロックの解放もしてよい。

あるいは、ＤＳＬＴ－ＣＦ１２１０は、ステップ８でリソースのロックができなかった場合、リソースが利用不可能である理由（リソースが存在しない、アクセス権が不適正である、リソースが既にロックされているなど）に関する表示を提供してよい。リソースがロックされている場合、ＤＳＬＴ－ＣＦ１２１０は、（ロックリソースに関連付けられたタイムアウトに基づいて）リソースがいつアンロックされる可能性があるかの時間の表示を提供してもよい。この場合、ＤＳＬＴ－ＭＦ１２０４は、（ＤＳＬＴ－ＣＦ１２１０によって提供された情報に基づいて）しばらくしてからトランザクションの再試行を試みてよい。

図２１のステップ１１では、ＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４は、各ターゲットＤＳＬＴ－ＣＦ１２０８および１２１０にリクエストを送信して、トランザクションを実行するようコマンドする。このコマンドは、ＤＳＬＴ－ＭＦ１２０４によって発行されてよく、各ＩｏＴデバイスでホストされているＤＳＬＴリソース内のコマンド属性を更新し、ＤＳＬＴ－ＣＦ１２０８および１２１０にトランザクションを実行するように命令する。

図２１のステップ１２では、トランザクションの実行のコマンドを受信すると、各デバイスのＤＳＬＴ－ＣＦ１２１０は、ターゲットリソースでトランザクションに規定された操作を実施する。ターゲットリソースでの操作の結果として、ＩｏＴデバイスの複数のリソースの状態が変化することもある。ＤＳＬＴ－ＲＥＱが中止され、ロールバックされる必要がある場合に、必要があれば、ＤＳＬＴ－ＣＦ１２１０は（操作の実行前の）操作前の状態のコピーを保持する。

図２１のステップ１３では、一旦、実行が完了すると、各ＤＳＬＴ－ＣＦ１２１０は、実行結果、およびそれが成功したのか否かについて、ＤＳＬＴ－ＭＦ１２０４に応答を返す。

図２１のステップ１４では、全てのターゲットＤＳＬＴ－ＣＦ（すなわち、ＩｏＴデバイス１２３４および１２３６の両方）がターゲットリソースでトランザクションを正常に実行したと応答したことを、ＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４が検出する。その結果、ＤＳＬＴ－ＭＦ１２０４は、結果（例えば、更新されたリソース表現）を耐久的なものにし、かつリソースおよびその更新済み状態に他のトランザクションがアクセスできるようにリソースのロックを解放することによって結果をコミットするように、ターゲットＤＳＬＴ－ＣＦ１２０８および１２１０に続いて命令してよいと判断する。ＤＳＬＴ－ＭＦ１２０４は、全てのターゲットから正常な実行の応答を受信しなかった場合は、いずれかの完了基準がトランザクションに設定されているか、またはそのポリシーのいずれかで規定されているかをチェックすることができる。完了基準が規定されている場合、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＭＦ１２０４が手順を進めることが基準によって許容されているかどうかをチェックしてよい（例えば、基準は、トランザクションが全てのターゲットではなく、ターゲットのサブセットで完了することのみを要すると規定している場合がある）。あるいは、実行されたトランザクションのうちの１つまたは複数が失敗した場合、ＤＳＬＴ－ＭＦ１２０４は、トランザクションがその設定パラメータまたはポリシー設定を介して再試行されるように設定されているか否かチェックしてよい。再試行が許可されている場合、ＤＳＬＴ－ＭＦ１２０４は失敗したトランザクションを再試行してもよい。完了基準を満たすことができず、トランザクションの再試行ができないとＤＳＬＴ－ＭＦ１２０４が判断した場合、ＤＳＬＴ－ＭＦ１２０４はトランザクションの中止を選択してよい。トランザクションを中止するために、ＤＳＬＴ－ＭＦ１２０４は、トランザクションターゲットのそれぞれ（この例では、ＩｏＴデバイス１２３４および１２３６のＤＳＬＴ－ＣＦ）に中止コマンドを送信する。中止を受信すると、ＤＳＬＴ－ＣＦ１２１０は、トランザクションによって対象とされたリソースに対して行われたいずれの変更もトランザクションの開始前と同じ状態に戻されるようにロールバックすることによってトランザクションを中止する。ＤＳＬＴ－ＣＦ１２１０は、ターゲットリソースのロックの解放もしてよい。

図２１のステップ１５では、ＩｏＴサーバ１２３０のＤＳＬＴ－ＭＦ１２０４は、各ターゲットＤＳＬＴ－ＣＦ１２０８および１２１０にリクエストを送信して、トランザクションをコミットするようコマンドする。このコマンドは、ＤＳＬＴ－ＭＦ１２０４によって発行されてよく、各ＩｏＴデバイスでホストされているＤＳＬＴリソース内のコマンド属性を更新し、ＤＳＬＴ－ＣＦ１２０８および１２１０にトランザクションをコミットするように命令する。

図２１のステップ１６では、トランザクションをコミットするコマンドを受信すると、各デバイスのＤＳＬＴ－ＣＦ１２０８および１２１０は、トランザクション実行時に行われた可能性のあるリソースへのいずれの更新もその状態が耐久的なものとなるように保存する。ＤＳＬＴ－ＣＦ１２０８および１２１０は、コミットされるリソースの状態のいずれかの更新に基づいて、ターゲットリソースにサブスクライブした可能性のあるシステム内のいずれの他のエンティティにも更新状態に関する通知を送信してもよい。次いで、ＤＳＬＴ－ＣＦ１２０８および１２１０は、ターゲットリソースのいずれのロックも解放し、保存した操作前状態のいずれも削除してよい。

図２１のステップ１７では、一旦、コミットが完了すると、各ＤＳＬＴ－ＣＦ１２０８および１２１０は、コミット結果、およびそれが成功したか否かと共に、ＤＳＬＴ－ＭＦ１２０４に応答を返す。

図２１のステップ１８では、全てのターゲットＤＳＬＴ－ＣＦ１２０８および１２１０（すなわち、ＩｏＴデバイス１２３４および１２３６の両方）がターゲットリソースでトランザクションを正常にコミットしたと応答したことを、ＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４が検出する。コミットのうちの１つまたは複数が失敗した場合、ＤＳＬＴ－ＭＦ１２０４は、トランザクションがその設定パラメータまたはポリシー設定を介して再試行されるように設定されているか否かチェックしてもよい。再試行が許可されている場合、ＤＳＬＴ－ＭＦ１２０４は失敗したトランザクションを再試行してもよい。完了基準を満たすことができず、トランザクションの再試行ができないとＤＳＬＴ－ＭＦ１２０４が判断する場合は、ＤＳＬＴ－ＭＦ１２０４はトランザクションのエラー状況を報告してよい。

図２１のステップ１９では、ＤＳＬＴ－ＭＦ１２０４は、ＩｏＴアプリケーションのＤＳＬＴ－ＴＦ１２０２から受信したＤＳＬＴに対応する、そのローカルにホストされているＤＳＬＴリソースを更新する。この更新には、ＩｏＴデバイスに配布して、トランザクションが成功したかどうか、および、成功しなかった場合はその失敗の原因または理由を示すＤＳＬＴのそれぞれのステータスが含まれる。

図２１のステップ２０では、一旦、ＤＳＬＴ処理が完了すると、ＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４は、ＩｏＴアプリケーションのＤＳＬＴ－ＴＦ１２０２に、ＤＳＬＴの結果を含めて通知してよい。ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴの全体的なステータスおよび個々のターゲットで実施された各配布されたトランザクションの個々のステータスを含めてよい。これは、失敗の原因を説明するエラーまたはデバッグ情報を含んでよい。これにより、技術者およびオペレータは、問題を検出して、別のＤＳＬＴの発行を再試行する前に障害のあるデバイスを交換または修復できる。

図２１のステップ２１では、完了したＤＳＬＴの通知を受信した後、ＩｏＴアプリケーションのＤＳＬＴ－ＴＦ１２０２は、ＤＳＬＴ－ＭＦ１２０４に、通知受信の確認を応答してよい。

図２１のステップ２２では、いずれかの時点で、ＩｏＴアプリケーションのＤＳＬＴ－ＴＦ１２０２がＤＳＬＴ処理のステータスのチェックを所望する場合、ステータスをチェックするようにＤＳＬＴ－ＭＦ１２０４に問い合わせしてもよい。問い合わせリクエストを受信すると、ＤＳＬＴ－ＭＦ１２０４は、対応するＤＳＬＴリソース内で保持しているＤＳＬＴの状態をチェックしてよい。

図２１のステップ２３では、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴステータス問い合わせを開始したＤＳＬＴ－ＴＦ１２０２にＤＳＬＴ処理の状態を返す。

（ＤＳＬＴシーケンスプロシージャ）
図２２は、ＤＳＬＴシーケンスプロシージャを示す図である。

図２２のステップ１は、任意のステップである。図２２のステップ１では、ＩｏＴアプリケーションのＤＳＬＴ－ＴＦ１２０２が、ＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４にＤＳＬＴシーケンスポリシーリソースを生成するようリクエストを送信する。各ポリシーリソースは、ＤＳＬＴ－ＭＦがＤＳＬＴシーケンスリクエストをどのように処理するか制御する１つまたは複数のルールを含んでよい。これらのルールは、ＤＳＬＴシーケンススケジューリング、ＤＳＬＴシーケンスの再試行、ＤＳＬＴシーケンスの優先順位付け、ならびに、ＤＳＬＴシーケンス向けの実行基準および完了基準に関連してよい。あるいは、ＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴシーケンスポリシーを用いて事前にプロビジョンされてもよい。

図２２のステップ２は、任意のステップである。図２２のステップ２では、ＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４は、リクエストを受信し処理し、ＤＳＬＴシーケンスポリシーリソースを生成する。ＤＳＬＴ－ＭＦ１２０４はポリシーリソースを生成し、さらに、ポリシーで規定されたルールによってそのＤＳＬＴポリシーエンジン１３０８の設定も行う。

図２２のステップ３は、任意のステップである。図２２のステップ３では、ＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４は、ＩｏＴアプリケーションのＤＳＬＴ－ＴＦ１２０２に応答を返して、ポリシーリソースで定義されたルールが受諾されたか否か通知する。受諾されなかった場合、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＭＦ１２０４によって受諾されたルールの修正バージョンを提供してよい。

図２２のステップ４では、ＩｏＴアプリケーションのＤＳＬＴ－ＴＦ１２０２がＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４にＤＳＬＴ－ＳＥＱ－ＴＲＩＧＧＥＲリクエストを送信する。リクエストは、ターゲットノード（例えば、ＩｏＴデバイス１およびＩｏＴデバイス２）のセット、これらのノードで実施するＤＳＬＴのリスト、シーケンスをいつ実施するかのスケジュール、シーケンス実行基準のセット、優先順位、トランザクションのシーケンスの処理の試みが失敗した場合の再試行の回数、シーケンス完了基準のセット、ＤＳＬＴ－ＭＦ１２０４がシーケンスを非ブロッキング式に処理するのに使用し得るＤＳＬＴシーケンス識別子およびコンタクト情報などのいくつかのパラメータを含んでよい。

図２２のステップ５では、ＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＳＥＱ－ＴＲＩＧＧＥＲリクエストを受信して処理を開始する。ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴシーケンスリソースを生成して、ＤＳＬＴシーケンスの処理の間、トランザクションシーケンスの状態を追跡する。ＤＳＬＴ－ＭＦ１２０４は、ステップ４で示したＤＳＬＴシーケンスリクエストパラメータに含まれた情報を用いてリソースの属性を構成する。

図２２のステップ６では、ＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４は、リクエストを受信して処理を開始したことを示す応答をＩｏＴアプリケーションのＤＳＬＴ－ＴＦ１２０２に返すことによって、リクエストを非ブロッキング式に処理する。あるいは、ＤＳＬＴ－ＭＦ１２０４は、このリクエストをブロッキング式に処理してもよい。

図２２のステップ７では、ＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４は、リクエストを解析し、シーケンスによって対象とされるリソースのリストを見つける。ＤＳＬＴ－ＭＦ１２０４は、ターゲットリソースが、ＩｏＴサーバでローカルにホストされておらず、ＩｏＴデバイス１および２によってホストされていることを検出する。その後、ＤＳＬＴ－ＭＦ１２０４は、これらのターゲットデバイスに配布するシーケンス内の最初の／次の対応するＤＳＬＴを準備する。ＤＳＬＴの配布の前に、ＤＳＬＴ－ＭＦ１２０４はまず、スケジュール情報が元々のＤＳＬＴ－ＳＥＱ－ＴＲＩＧＧＥＲリクエストで、またはいずれかのスケジュール関連ポリシー内で明確に設定されたかどうかをチェックする。ＤＳＬＴ－ＭＦ１２０４はまた、優先順位が元々のＤＳＬＴ－ＳＥＱ－ＴＲＩＧＧＥＲリクエストで、またはいずれかのポリシーで明確に設定されたかどうかをチェックする。明確に設定されている場合、ＤＳＬＴ－ＭＦ１２０４は、既に受信して処理の必要があるその他のＤＳＬＴ－ＳＥＱ－ＴＲＩＧＧＥＲリクエストがあるかどうかをチェックする。ある場合、ＤＳＬＴ－ＭＦ１２０４は、優先順位情報を使用して、ＤＳＬＴ－ＳＥＱ－ＴＲＩＧＧＥＲリクエストの実行を互いに対して順位付けおよび順序付けする。一旦、スケジュールおよび優先順位によって順序付けが行われると、ＤＳＬＴ－ＭＦ１２０４は、それに応じてターゲットにＤＳＬＴ－ＲＥＱリクエストを配布する。

一旦、スケジュールおよび優先順位によって順序付けが行われると、ＤＳＬＴ－ＭＦ１２０４は、それに応じてターゲットにＤＳＬＴ－ＲＥＱを配布する。ＤＳＬＴ－ＭＦ１２０４の優先順位付けポリシーに応じて、処理が進行されているＤＳＬＴ－ＳＥＱ－ＴＲＩＧＧＥＲよりも優先順位の高い新たなＤＳＬＴ－ＳＥＱ－ＴＲＩＧＧＥＲが受信される場合は、ＤＳＬＴ－ＭＦ１２０４は、処理が進行されているＤＳＬＴ－ＳＥＱ－ＴＲＩＧＧＥＲを完了するか、または新たに届いた優先順位の高いＤＳＬＴ－ＳＥＱ－ＴＲＩＧＧＥＲを処理するために割り込みしてもよい。シーケンスを割り込みする場合は、ＤＳＬＴ－ＭＦ１２０４は、後で処理を再開するのに有利なように、シーケンスを中止してロールバックするか、またはＤＳＬＴ－ＭＦ１２０４は、優先順位の高いシーケンスを処理している間シーケンスの処理およびその関連するＤＳＬＴを一時停止し、その後処理を再開してよい。中止するか割り込みするかの判断は、優先順位の高いシーケンスが、処理が進行されている優先順位の低いシーケンスと同じリソースを対象としているかどうかなど、いくつかの要因に基づくものであってよい。この場合、ＤＳＬＴ－ＭＦ１２０４は優先順位の低いシーケンスの中止を決定してよいが、その一方で、２つのシーケンスが異なるリソースを対象としているケースでは、ＤＳＬＴ－ＭＦ１２０４は、優先順位の低いシーケンスへの割り込みを選択するか、またはサポートされている場合は、両方のシーケンスを並行して実行してもよい。

図２２のステップ８では、ＩｏＴデバイス１２３４および１２３６のＤＳＬＴ－ＣＦ１２０８および１２１０は、それぞれのＤＳＬＴ－ＲＥＱを受信する。どちらともリクエストを処理し、ローカルＤＳＬＴリソースを生成して、ＤＳＬＴを処理している間、トランザクションの状態を追跡する。ＤＳＬＴ－ＣＦ１２０８および１２１０は、ＤＳＬＴ－ＲＥＱパラメータ内に含まれている情報を用いてそれらのリソースの属性を構成する。ＤＳＬＴ－ＣＦ１２０８および１２１０は、まず、ターゲットリソースの利用可能性をチェックすることによってトランザクションの処理を開始する。リソースがＩｏＴデバイスに対してローカルの場合、ＤＳＬＴ－ＣＦ１２１０は、規定操作を実施するためのリソースの利用可能性、ならびに現時点でリソースを予約およびロックしている他のトランザクションがないことをチェックする。リソースが利用可能な場合は、ＤＳＬＴ－ＣＦ１２１０は、現在のトランザクションの処理中に届く可能性のある他のトランザクションからの干渉を受けることなく、該リソースでトランザクションを実施してもよいようにリソースをロックしてよい。ＤＳＬＴ－ＣＦ１２１０がＤＳＬＴ－ＲＥＱを受信して、リクエストがローカルデバイスでホストされていないリソースを対象としていることを見つける場合、ＤＳＬＴ－ＣＦ１２１０は、（場合によっては、デバイスでローカルにホストされているＤＳＬＴ－ＭＦ１２０４の支援によって）その他のデバイスのＤＳＬＴ－ＣＦがそれを処理できるように、システム内の別のデバイスに向けてＤＳＬＴ－ＲＥＱを再対象としてよい。

図２２のステップ９では、各ＩｏＴデバイスのＤＳＬＴ－ＣＦ１２１０は、リクエストが受信されて、トランザクションで処理が開始して、ターゲットリソースが利用可能であり、リソースがロックされて、他のトランザクションから干渉を受けることなく現在のトランザクションが処理できることを示すステータスをＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４に返す。

図２２のステップ１０では、全てのターゲットＤＳＬＴ－ＣＦ１２０８および１２１０（すなわち、ＩｏＴデバイス１２３４および１２３６の両方）が、ターゲットリソースを正常にロックしたと応答したことを、ＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４が検出する。その結果、ＤＳＬＴ－ＭＦ１２０４は、トランザクションの実行をするように、ターゲットＤＳＬＴ－ＣＦ１２１０に続いて命令してよいと判断する。ＤＳＬＴ－ＭＦ１２０４が全てのターゲットから正常なロックの応答を受信しなかった場合、いずれかの完了基準がトランザクションのために設定されているか、またはそのポリシーのいずれかで規定されているかをチェックすることができる。完了基準が規定されている場合、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＭＦ１２０４が手順を進めることを基準によって許容されているかどうかをチェックしてよい（例えば、基準は、トランザクションが全てのターゲットではなく、ターゲットのサブセットで完了することのみを要すると規定している場合がある）。あるいは、トランザクションのうちの１つまたは複数がターゲットリソースのロックに失敗した場合、ＤＳＬＴ－ＭＦ１２０４は、トランザクションがその設定パラメータまたはポリシー設定を介して再実行されるように構成されているのか否かチェックしてよい。再試行が許可されている場合、ＤＳＬＴ－ＭＦ１２０４は失敗したトランザクションを再試行してもよい。完了基準を満たすことができず、トランザクションの再試行ができないとＤＳＬＴ－ＭＦ１２０４が判断する場合は、ＤＳＬＴ－ＭＦ１２０４はトランザクションの中止を選択してよい。トランザクションを中止するために、ＤＳＬＴ－ＭＦ１２０４は、トランザクションターゲットのそれぞれ（この例では、ＩｏＴデバイス１２３４および１２３６のＤＳＬＴ－ＣＦ１２０８および１２１０）に中止コマンドを送信する。中止を受信すると、ＤＳＬＴ－ＣＦ１２１０は、トランザクションによって対象とされたリソースに対して行われたいずれの変更もトランザクションの開始前と同じ状態に戻されるようにロールバックすることによってトランザクションを中止する。ＤＳＬＴ－ＣＦ１２１０は、ターゲットリソースのロックの解放もしてよい。

あるいは、ＤＳＬＴ－ＣＦ１２１０は、ステップ８でリソースのロックができなかった場合、リソースが利用不可能である理由（リソースが存在しない、アクセス権が不適正である、リソースが既にロックされているなど）に関する表示を提供してよい。リソースがロックされている場合、ＤＳＬＴ－ＣＦ１２１０は、（ロックリソースに関連付けられたタイムアウトに基づいて）リソースがいつアンロックされる可能性があるかの時間の表示を提供してもよい。この場合、ＤＳＬＴ－ＭＦ１２０４は、（ＤＳＬＴ－ＣＦ１２１０によって提供された情報に基づいて）しばらくしてからトランザクションの再試行行を試みてよい。

図２２のステップ１１では、ＩｏＴサーバ１２３０のＤＳＬＴ－ＭＦ１２０４は、各ターゲットＤＳＬＴ－ＣＦ１２０８および１２１０にリクエストを送信して、トランザクションを実行するようにコマンドする。このコマンドは、ＤＳＬＴ－ＭＦ１２０４によって発行されてよく、各ＩｏＴデバイス１２３４および１２３６でホストされているＤＳＬＴリソース内のコマンド属性を更新し、ＤＳＬＴ－ＣＦ１２０８および１２１０にトランザクションを実行するように命令する。

図２２のステップ１２では、トランザクションの実行のコマンドを受信すると、各デバイスのＤＳＬＴ－ＣＦ１２０８および１２１０は、ターゲットリソースでトランザクションに規定された操作を実施する。ターゲットリソースでの操作の結果として、ＩｏＴデバイスの複数のリソースの状態が変化することもある。ＤＳＬＴ－ＲＥＱが中止され、ロールバックされる必要がある場合に、必要があれば、ＤＳＬＴ－ＣＦ１２０８および１２１０は（操作の実行前の）操作前の状態のコピーを保持する。

図２２のステップ１３では、一旦、実行が完了すると、各ＤＳＬＴ－ＣＦ１２０８および１２１０は、実行結果、およびそれが成功したのか否かについて、ＤＳＬＴ－ＭＦ１２０４に応答を返す。

図２２のステップ１４では、全てのターゲットＤＳＬＴ－ＣＦ１２０８および１２１０（すなわち、ＩｏＴデバイス１２３４および１２３６の両方）がターゲットリソースでトランザクションを正常に実行したと応答したことを、ＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４が検出する。次いで、ＤＳＬＴ－ＭＦ１２０４は、シーケンス内に残存するＤＳＬＴがあるかどうかをチェックする。残存するＤＳＬＴがある場合、ＤＳＬＴ－ＭＦ１２０４は、次のＤＳＬＴを準備して、ステップ７～１４を繰り返す。シーケンス内に残存するＤＳＬＴがない場合、ＤＳＬＴ－ＭＦ１２０４は、シーケンスの一部として処理された全てのＤＳＬＴの結果をコミットするように、ターゲットＤＳＬＴ－ＣＦ１２０８に続いて命令してよいと判断する。結果を耐久的にすること、かつリソースのロックを解放することによって、リソースおよびその更新状態に他のトランザクションがアクセスできるようにする。ＤＳＬＴ－ＭＦ１２０４は、全てのターゲットから正常な実行の応答を受信しなかった場合、いずれかの完了基準がトランザクションに設定されているか、またはそのポリシーのいずれかで規定されているかをチェックすることができる。完了基準が規定されている場合、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴ－ＭＦ１２０４が手順を進めることが基準によって許容されているかどうかをチェックしてよい（例えば、基準は、全てのターゲットではなく、ターゲットのサブセットのみでトランザクションが完了することが必要とされると規定している場合がある）。あるいは、実行されたトランザクションのうちの１つまたは複数が失敗した場合、ＤＳＬＴ－ＭＦ１２０４は、トランザクションがその設定パラメータまたはポリシー設定を介して再試行されるように設定されているか否かチェックしてよい。再試行が許可されている場合、ＤＳＬＴ－ＭＦ１２０４は失敗したトランザクションを再試行してもよい。完了基準を満たすことができず、トランザクションの再試行ができないとＤＳＬＴ－ＭＦ１２０４が判断する場合、ＤＳＬＴ－ＭＦ１２０４はトランザクションの中止を選択してよい。トランザクションを中止するために、ＤＳＬＴ－ＭＦ１２０４は、トランザクションターゲットのそれぞれ（この例では、ＩｏＴデバイス１２３４および１２３６のＤＳＬＴ－ＣＦ１２０８および１２１０）に中止コマンドを送信する。中止を受信すると、ＤＳＬＴ－ＣＦ１２０８および１２１０はシーケンス内の各トランザクションを中止することによってシーケンスを中止する。これにより、シーケンス内のトランザクションによって対象とされていたリソースに対して行われたいずれの変更もシーケンスの開始前と同じ状態に戻されるようにロールバックされる。ＤＳＬＴ－ＣＦ１２０８および１２１０は、ターゲットリソースのロックの解放もしてよい。

図２２のステップ１５では、ＩｏＴサーバ１２３０のＤＳＬＴ－ＭＦ１２０４は、各ＤＳＬＴが実行された各ターゲットＤＳＬＴ－ＣＦ１２０８および１２１０に一連のコミットリクエストを送信する。このコマンドは、ＤＳＬＴ－ＭＦ１２０４によって発行されてよく、各ＩｏＴデバイス１２３４および１２３６でホストされているＤＳＬＴリソース内のコマンド属性を更新し、ＤＳＬＴ－ＣＦ１２０８および１２１０にトランザクションをコミットするように命令する。

図２２のステップ１６では、所定のＤＳＬＴをコミットする各コマンドを受信すると、各デバイスのＤＳＬＴ－ＣＦ１２０８および１２１０は、トランザクション実行時に行われた可能性のあるリソースへのいずれの更新もその状態が耐久的なものとなるように保存する。ＤＳＬＴ－ＣＦ１２０８および１２１０は、コミットされるリソースの状態のいずれの更新にも基づいて、ターゲットリソースにサブスクライブした可能性のあるシステム内のいずれの他のエンティティにも更新状態に関する通知を送信してもよい。次いで、ＤＳＬＴ－ＣＦ１２０８および１２１０は、ターゲットリソースのいずれのロックも解放し、保存した操作前状態のいずれも削除してよい。

図２２のステップ１７では、一旦、各コミットが完了すると、各ＤＳＬＴ－ＣＦ１２０８および１２１０は、コミット結果、およびそれが成功したか否かと共に、ＤＳＬＴ－ＭＦ１２０４に応答を返す。

図２２のステップ１８では、全てのターゲットＤＳＬＴ－ＣＦ１２０８および１２１０（すなわち、ＩｏＴデバイス１２３４および１２３６の両方）がそれぞれのターゲットリソースでシーケンス内の全てのトランザクションを正常にコミットしたと応答したことを、ＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４が検出する。コミットのうちの１つまたは複数が失敗した場合、ＤＳＬＴ－ＭＦ１２０４は、それぞれのトランザクションシーケンスがその設定パラメータまたはポリシー設定を介して再実行されるように構成されているか否かチェックしてよい。再試行が許可されている場合、ＤＳＬＴ－ＭＦ１２０４は失敗したトランザクションシーケンスを再試行してもよい。完了基準を満たすことができず、トランザクションシーケンスの再試行ができないとＤＳＬＴ－ＭＦ１２０４が判断する場合は、ＤＳＬＴ－ＭＦ１２０４はトランザクションシーケンスのエラー状況を報告することを選択してもよい。

図２２のステップ１９では、ＤＳＬＴ－ＭＦ１２０４は、ＩｏＴアプリケーションのＤＳＬＴ－ＴＦ１２０２から受信したＤＳＬＴ－ＳＥＱ－ＴＲＩＧＧＥＲリクエストに対応する、そのローカルにホストされているＤＳＬＴシーケンスリソースを更新する。この更新には、ＩｏＴデバイスに配布されるシーケンス内のＤＳＬＴのそれぞれのステータスが含まれる。このステータスは、トランザクションシーケンスが成功したかどうかを示し、成功しなかった場合はその失敗の理由を示す。ＤＳＬＴ－ＭＦ１２０４は、シーケンス内の失敗したいずれのＤＳＬＴの個々のステータスおよび失敗の情報も含めてもよい。

図２２のステップ２０では、一旦、ＤＳＬＴシーケンス処理が完了すると、ＩｏＴサーバのＤＳＬＴ－ＭＦ１２０４は、ＩｏＴアプリケーションのＤＳＬＴ－ＴＦ１２０２にＤＳＬＴシーケンスの結果を含めて通知してよい。ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴシーケンスの全体的なステータスおよび個々のターゲットで実施されたシーケンス内の各配布されたトランザクションの個々のステータスを含めてよい。これは、失敗の原因を説明するエラーまたはデバッグ情報を含んでよい。これにより、技術者およびオペレータは、問題を検出して、別のＤＳＬＴの発行を再試行する前に障害のあるデバイスを交換または修復できる。

図２２のステップ２１では、完了したＤＳＬＴシーケンスの通知の受信後、ＩｏＴアプリケーションのＤＳＬＴ－ＴＦ１２０２は、ＤＳＬＴ－ＭＦ１２０４に、通知受信の確認を応答してよい。

図２２のステップ２２では、いずれかの時点で、ＩｏＴアプリケーションのＤＳＬＴ－ＴＦ１２０２がＤＳＬＴシーケンス処理のステータスのチェックを所望する場合、ステータスをチェックするようにＤＳＬＴ－ＭＦ１２０４に問い合わせしてよい。問い合わせリクエストを受信すると、ＤＳＬＴ－ＭＦ１２０４は、対応するＤＳＬＴシーケンスリソース内で保持しているＤＳＬＴシーケンスの状態をチェックしてよい。

図２２のステップ２３では、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴステータス問い合わせを開始したＤＳＬＴ－ＴＦ１２０２にＤＳＬＴシーケンス処理の状態を返す。

（ｏｎｅＭ２Ｍ分散サービス層トランザクション実施形態）
ｏｎｅＭ２Ｍアーキテクチャ[oneM2M TS-0001]を対象とするＤＳＬＴメカニズムおよびプロシージャのいくつかの実施形態について以下に説明する。ＤＳＬＴサポートをｏｎｅＭ２Ｍアーキテクチャに加えることで、全てのリクエストが正常に実施されるか、またはいずれのリクエストも実施されないかどちらかとなるような原子的に実施される複数のリソースをターゲットとするリクエストのセットを可能にする。

ＤＳＬＴ－ＭＦ１２０４および／またはＤＳＬＴ－ＣＦ１２１０は、ｏｎｅＭ２Ｍアーキテクチャの内部で、図２３に示すように、共通サービスエンティティ（ＣＳＥ）（すなわち、サービス層エンティティ）の新しいトランザクション管理共通サービス機能（ＣＳＦ）として実現可能である。

このトランザクション管理ＣＳＦ２３０４は、ｏｎｅＭ２ＭシステムにおいてＤＳＬＴサポートを可能にするために使用されてよい。あるいは、ＤＳＬＴ－ＭＦ１２０４は、１つまたは複数の既存のｏｎｅＭ２Ｍ ＣＳＦ（図１～６に示さず）の性能として実現されてもよい。

ＤＳＬＴ－ＴＦ１２０２および／またはＤＳＬＴ－ＣＦ１２１０の機能は、ｏｎｅＭ２Ｍアプリケーションエンティティ（ＡＥ）２３０６によってサポートされてもよい。例えば、ＡＥ２３０６はそのＤＳＬＴ－ＴＦ１２０２を介してＤＳＬＴリクエストを開始して、ＣＳＥ２３０２によってホストされているＤＳＬＴ－ＭＦ２３０４にこのリクエストを送信してもよい。あるいは、ＡＥ２３０６は、ＣＳＥによってホストされているＤＳＬＴ－ＭＦ１２０４からそのＤＳＬＴ－ＣＦ１２１０を介してＤＳＬＴリクエストを受信してもよい。

ＣＳＥ２３０２およびＡＥ２３０６がＤＳＬＴ機能をサポートすることを可能にするために、以下のサブセクションでは、いくつかのＤＳＬＴｏｎｅＭ２Ｍ実施形態を定義する。

（ｏｎｅＭ２ＭリクエストパラメータへのＤＳＬＴ拡張）
ｏｎｅＭ２ＭアーキテクチャでＤＳＬＴをサポートするために、ＤＳＬＴおよびＤＳＬＴシーケンスメッセージパラメータのそれぞれに対して新しいｏｎｅＭ２Ｍリクエストパラメータが表３および表４で定義されている。これらのパラメータをｏｎｅＭ２Ｍリクエスト内でサポートすることで、複数のｏｎｅＭ２Ｍリクエストを互いに関連付けてｏｎｅＭ２Ｍリクエストのセットとして一緒に原子的に処理することを可能にする。

トランザクションベースの処理をサポートするために、既存のｏｎｅＭ２Ｍ応答タイプパラメータを拡張して、非ブロッキングトランザクションリクエスト同期（ｎｏｎＢｌｏｃｋｉｎｇＴｒａｎｓａｃｔｉｏｎＲｅｑｕｅｓｔＳｙｎｃｈ）および非ブロッキングトランザクションリクエスト非同期（ｎｏｎＢｌｏｃｋｉｎｇＴｒａｎｓａｃｔｉｏｎＲｅｑｕｅｓｔＡｓｙｎｃｈ）の２つの追加の非ブロッキング応答タイプを追加サポートしてもよい。これらの２つの応答タイプは、非ブロッキングであり原子的なトランザクションとしてホスティングＣＳＥによってリクエストが処理されることを規定するために、発信元によって使用されてよい。これらの新しい値の１つに設定された応答タイプを備えるリクエストを受信するときに、ホスティングＣＳＥは、後のセクションに記載されているような、ｏｎｅＭ２Ｍ＜ｒｅｑｕｅｓｔ＞リソースへの追加の新しいトランザクション指向属性をサポートしてよい。これらの新しいトランザクション指向応答タイプおよび＜ｒｅｑｕｅｓｔ＞属性により、後のセクションに詳述されているプロシージャにてさらに記載されているような原子的なトランザクション指向方式で、ホスティングＣＳＥがプリミティブを処理することを可能にする。あるいは、ホスティングＣＳＥは、他の方法で、例えば、いくつかの追加のＤＳＬＴ属性または＜ｓｅｑｕｅｎｃｅ＞リソースと共に、＜ｔｒａｎｓａｃｔｉｏｎ＞リソースをサポートすることによっても、同様にＤＳＬＴをサポートしてもよい。

（ｏｎｅＭ２Ｍ ＤＳＬＴリソース）
ｏｎｅＭ２ＭアーキテクチャでＤＳＬＴをサポートするために、いくつかのＤＳＬＴ関連属性が使用されてよい。これらの属性は、図２４に示すように、＜ｒｅｑｕｅｓｔ＞リソースまたは＜ｔｒａｎｓａｃｔｉｏｎ＞リソースなどの既存のｏｎｅＭ２Ｍリソースに加えられてよい。あるいは、新しいリソースタイプは、これらの属性をサポートするように定義されてもよい。新しいリソースタイプが定義されているケースでは、完全なソリューションを提供するために、＜ｒｅｑｕｅｓｔ＞リソースおよび／または＜ｔｒａｎｓａｃｔｉｏｎ＞リソースで既に定義されている属性のいくつかに類似する追加属性を組み込むことを必要としてもよい。これらの既存のｏｎｅＭ２Ｍ属性は、簡潔にするために組み込まれていなかった。１つの例は、ｏｎｅＭ２Ｍリクエストプリミティブに含まれるプリミティブ属性である。この属性は、＜ｒｅｑｕｅｓｔ＞リソースおよび＜ｔｒａｎｓａｃｔｉｏｎ＞リソースにて既存のものである（図示せず）。

これらの新しい属性により、発信元（例えば、ＡＥまたはＣＳＥ）がターゲットＣＳＥに対してＤＳＬＴリクエストを発行し、ＣＳＥにそのリクエストを非ブロッキング式かつ原子的に処理させることを可能にする。

（ｏｎｅＭ２Ｍ ＤＳＬＴシーケンスリソース）
ｏｎｅＭ２ＭアーキテクチャでＤＳＬＴシーケンスをサポートするために、いくつかのＤＳＬＴシーケンス属性を有する＜ｓｅｑｕｅｎｃｅ＞リソースを図２５に示す。

この新しいリソースおよび属性により、発信元（例えば、ＡＥまたはＣＳＥ）がＤＳＬＴシーケンスリクエストを発行し、ホスティングＣＳＥに非ブロッキング式にかつ原子的にＤＳＬＴのシーケンスを処理させることを可能にする。この処理は、シーケンス内の個別のＤＳＬＴが原子的に実行されること、およびＤＳＬＴのシーケンス全体も原子的に（すなわち、全てのＤＳＬＴが正常に実行されるか、またはいずれのＤＳＬＴも実行されないかどちらかとなるように）実行されることを保証するために、発信元に代わって、＜ｓｅｑｕｅｎｃｅ＞ホスティングＣＳＥによる個別のＤＳＬＴのシーケンスの処理を含んでよい。これにより、発信元からのＤＳＬＴシーケンスの処理のオーバーヘッドおよび負担を軽減することができる。この機能は、発信元が繰り返しリクエストを作成して、ＤＳＬＴシーケンスを送信する場合に、特に有用となる可能性がある。発信元は、これらの繰り返しＤＳＬＴシーケンスをそれ自体で処理しなければならないのではなく、この動作をその代わりに実施する＜ｓｅｑｕｅｎｃｅ＞ホスティングＣＳＥに肩代わりさせることができる。

シーケンス内のＤＳＬＴが＜ｓｅｑｕｅｎｃｅ＞ホスティングＣＳＥによってホストされているローカルリソースを対象とする場合、＜ｓｅｑｕｅｎｃｅ＞ホスティングＣＳＥは、これらのＤＳＬＴをそれ自体で原子的に処理してよい。この処理の間に、＜ｓｅｑｕｅｎｃｅ＞ホスティングＣＳＥは、これらのローカルリソースをロックして、処理が進行されているシーケンス内のＤＳＬＴによって規定された操作以外は、該ローカルリソースでいずれの操作も実施されないことを保証してよい。一旦、進行中のシーケンスの処理が正常に完了してコミットされると、このロックは解放されてよい。

シーケンス内のＤＳＬＴが、遠隔のＣＳＥでホストされているリソースを対象とする場合、＜ｓｅｑｕｅｎｃｅ＞ホスティングＣＳＥは、ＤＳＬＴ属性を有する遠隔ＣＳＥに＜ｒｅｑｕｅｓｔ＞または＜ｔｒａｎｓａｃｔｉｏｎ＞リソースを生成することによって、遠隔ＣＳＥにＤＳＬＴリクエストを送信してよい。＜ｓｅｑｕｅｎｃｅ＞ホスティングＣＳＥは、次いで、遠隔ＣＳＥのこれらの＜ｒｅｑｕｅｓｔ＞または＜ｔｒａｎｓａｃｔｉｏｎ＞リソースの状態を管理して、ＤＳＬＴが原子的に処理されることを保証してよい。＜ｓｅｑｕｅｎｃｅ＞ホスティングＣＳＥは、ターゲットリソースのロックを取得できるという遠隔ＣＳＥからの通知を待ってよい。一旦、通知が受信されると、次に、＜ｓｅｑｕｅｎｃｅ＞ホスティングＣＳＥは、遠隔ＣＳＥに、対応する＜ｒｅｑｕｅｓｔ＞または＜ｔｒａｎｓａｃｔｉｏｎ＞リソースのコマンド属性を更新することによってＤＳＬＴを実行するように命令してよい。次に、遠隔ＣＳＥは、トランザクションが正常に実行されたという遠隔ＣＳＥからの通知を待ってよい。一旦、通知が受信されると、＜ｓｅｑｕｅｎｃｅ＞ホスティングＣＳＥは、遠隔ＣＳＥに、対応する＜ｒｅｑｕｅｓｔ＞または＜ｔｒａｎｓａｃｔｉｏｎ＞リソースのコマンド属性がさらにまた更新されるまでに、結果が耐久的なものとなるようにトランザクションの結果をコミットするように命令してよい。次に、＜ｓｅｑｕｅｎｃｅ＞ホスティングＣＳＥは、結果が正常にコミットされたという遠隔ＣＳＥからの通知を待ってよい。一旦、コミットが成功したという通知が受信されると、＜ｓｅｑｕｅｎｃｅ＞ホスティングＣＳＥは、シーケンスリクエストの処理を完了して、その発信元に応答を返してよい。この応答は、ブロッキング式にまたは非ブロッキング式に返されてよい。この処理中のいずれかのステップにおいて、遠隔ＣＳＥがシーケンス内のいずれかのＤＳＬＴを正常にロック、実行またはコミットできなかった場合、＜ｓｅｑｕｅｎｃｅ＞ホスティングＣＳＥはシーケンスを中止して、対応する＜ｒｅｑｕｅｓｔ＞または＜ｔｒａｎｓａｃｔｉｏｎ＞リソースのコマンド属性がさらにまた更新されるまでに、これらのホスティングＣＳＥによって、ターゲットリソースがロールバックされることを保証してよい。このロールバックに続いて、リソースは、ＤＳＬＴシーケンス処理が開始される前と同じ状態に戻されてよい。

（ｏｎｅＭ２Ｍ ＤＳＬＴポリシーリソース）
ｏｎｅＭ２ＭアーキテクチャでＤＳＬＴポリシー構成をサポートするために、いくつかのＤＳＬＴポリシー属性を表１０に定義する。これらの属性は、ｏｎｅＭ２Ｍ ＣＭＤＨ機能について定義されたような既存のｏｎｅＭ２Ｍ＜ｍｇｍｔＯｂｊ＞特化などの既存のｏｎｅＭ２Ｍリソースに追加されてよい。あるいは、ＤＳＬＴ機能に固有の新しいｏｎｅＭ２Ｍ＜ｍｇｍｔＯｂｊ＞特化などのこれらの属性をサポートするように、新しいリソースタイプが定義されてもよい。例えば、新しい特化が、ＤＳＬＴスケジューリングポリシー、ＤＳＬＴ再試行ポリシー、ＤＳＬＴ優先順位付けポリシー、ＤＳＬＴ完了基準ポリシーおよびＤＳＬＴシーケンスポリシーに定義されてもよい。

これらの新しい属性により、発信元（例えば、ＡＥまたはＣＳＥ）は、ＤＳＬＴリクエストをＣＳＥがどう処理するかを制御するＤＳＬＴ関連ポリシーをＣＳＥ内に構成することができる。

（ｏｎｅＭ２Ｍ＜ｇｒｏｕｐ＞リソースへのＤＳＬＴ拡張）
１つまたは複数のＣＳＥでホストされている複数のターゲットリソースへの原子的な配布およびＤＳＬＴの処理をサポートするために、図２６に示すように、ｏｎｅＭ２Ｍ＜ｇｒｏｕｐ＞リソースへの新しい＜ｔｒａｎｓａｃｔｉｏｎＦａｎＯｕｔＰｏｉｎｔ＞仮想リソースおよび新しいｔｒａｎｓａｃｔｉｏｎＳｔａｔｅ属性が使用されてよい。この新しいリソースおよび属性は、ＤＳＬＴリクエストの発信元によって任意に使用されてよい。このリソースが使用された場合、グループホスティングＣＳＥが発信元に代わってＤＳＬＴリクエストの処理を取り扱ってよい。この処理には、グループによって規定されたメンバーリソースのそれぞれへのＤＳＬＴのファンアウトを含んでよい。メンバーリソースが遠隔ＣＳＥでホストされている場合、グループホスティングＣＳＥは、メンバーリソースを対象とする＜ｒｅｑｕｅｓｔ＞または＜ｔｒａｎｓａｃｔｉｏｎ＞リソースを生成することによって遠隔ＣＳＥへＤＳＬＴをファンアウトしてよい。処理には、グループホスティングＣＳＥが、対応する各メンバーリソースの各ＤＳＬＴの状態を管理することを含んでもよい。これは、発信元の代わりに行われて、ＤＳＬＴが互いに対して原子的に（すなわち、全てが正常に実行されるか、またはいずれも実行されないかのどちらか一方で）実行されることを保証してもよい。これにより、発信元からのＤＳＬＴの処理のオーバーヘッドおよび負担を軽減することができる。この機能は、発信元が、繰り返しリクエストを作成して、多数のターゲットにＤＳＬＴを送信する場合に、特に有用となる可能性がある。発信元は、多数のターゲットリソース向けにこれらの繰り返しＤＳＬＴをそれ自体で処理しなければならないのではなく、この動作をその代わりに実施するグループホスティングＣＳＥに肩代わりさせることができる。あるいは、ＤＳＬＴの発信元がＤＳＬＴをそれ自体で管理する場合は、発信元はこの新しいリソースを使用せずにその管理を行ってもよい。

この仮想リソースは表現を持たないが、＜ｇｒｏｕｐ＞リソースの子リソースである。ｏｎｅＭ２Ｍリクエストプリミティブが、＜ｔｒａｎｓａｃｔｉｏｎＦａｎＯｕｔＰｏｉｎｔ＞リソースに送信される場合は常に、グループホスティングＣＳＥは、親＜ｇｒｏｕｐ＞リソースのｍｅｍｂｅｒＩＤ属性によって規定されたメンバーのそれぞれに、対応するＤＳＬＴ ＣＲＥＡＴＥリクエストをファンアウトすることによってリクエストを処理してよい。発信元またはグループホスティングＣＳＥで構成されるローカルポリシーによって規定されている場合、メンバーにファンアウトする各ＤＳＬＴ ＣＲＥＡＴＥリクエスト向けに、グループホスティングＣＳＥは、発信元から受信した元のリクエストプリミティブを有する属性、「Ｉｎｉｔｉａｌ」の値を有する状態属性、結果の満了時間パラメータよりも小さな値を有するｅｘｅｃｕｔｉｏｎＴｉｍｅ属性を構成してよい。その後、グループホスティングＣＳＥは、ファンアウトされたＤＳＬＴリクエストの取り扱いを、互いに対して原子的に（すなわち、ファンアウトされたトランザクションの全てが正常に完了するか、またはその全てが中止されるかのどちらか一方で）全て処理されるように調整してよい。メンバーホスティングＣＳＥにファンアウトされたＤＳＬＴ ＣＲＥＡＴＥリクエストに対して、これらのＣＳＥは、規定された実行時間においてメンバーリソースで規定されたプリミティブを実施できるかどうかをチェックしてよい。チェックが成功する場合、メンバーホスティングＣＳＥは、ＤＳＬＴを正常に生成したと、グループホスティングＣＳＥに応答を返してよい。チェックが成功しない場合、メンバーホスティングＣＳＥは、その失敗結果と共に応答を返してもよい。トランザクションの処理に対して、グループホスティングＣＳＥによってタイマーが継続されてよい。タイマーの満了前に各メンバーホスティングＣＳＥからＤＳＬＴの正常生成の応答が受信される場合、トランザクションを次に進めて実行することができる。グループホスティングＣＳＥは、任意選択でコマンドを各メンバーホスティングＣＳＥに送信して、トランザクションを実行し、コミットすることを命令してよい。トランザクションが進行できない場合、グループホスティングＣＳＥは、ＤＳＬＴを正常に生成したと示したいずれのメンバーホスティングＣＳＥにも、ＤＳＬＴ ＤＥＬＥＴＥリクエストを送信することによってトランザクションを中止してもよい。トランザクションが実行できる場合、メンバーで実行した各リクエストプリミティブからの個々の応答は、グループホスティングＣＳＥに返されてよい。次に、グループホスティングＣＳＥは、応答を集約して、発信元に結果を返してよい。応答の集約のためにグループホスティングＣＳＥによってタイマーが継続されてもよい。全ての応答が受信されるか、タイマーが満了すると、応答は集約される。時間満了後に受信される応答は、破棄されてよい。この処理中のいずれかのステップにおいて、グループホスティングＣＳＥが、グループメンバーのそれぞれから、ＤＳＬＴをロック、実行またはコミットできるという成功の確認を受け取らない場合は、グループホスティングＣＳＥは、ＤＳＬＴを中止して、ターゲットメンバーリソースがそれぞれのメンバーホスティングＣＳＥによってロールバックされることを保証してよい。このロールバックに続いて、リソースは、ＤＳＬＴ処理が開始される前と同じ状態に戻されてよい。グループホスティングＣＳＥは、トランザクションの処理状態（例えば、開始（ｉｎｉｔｉａｌ）、ロックされた（ｌｏｃｋｅｄ）、実行された（ｅｘｅｃｕｔｅｄ）、コミットされた（ｃｏｍｍｉｔｔｅｄ）、または中止された（ａｂｏｒｔｅｄ））を用いて更新されたｔｒａｎｓａｃｔｉｏｎＳｔａｔｅ属性を保持してもよい。

別の実施形態では、新しい属性（例えば、ｔｒａｎｓａｃｔｉｏｎＦａｎＯｕｔＥｎａｂｌｅ）が、代わりに＜ｇｒｏｕｐ＞リソースに追加されてもよい。この属性を使用して、＜ｇｒｏｕｐ＞の既存の＜ｆａｎＯｕｔＰｏｉｎｔ＞仮想リソースを対象とするリクエストが、ＤＳＬＴまたは非ＤＳＬＴリクエストとして次に進むべきかどうかを限定してよい。この選択肢については、図２６に示していない。

さらに別の実施形態では、グループホスティングＣＳＥは、代わりに、ｏｎｅＭ２Ｍ＜ｇｒｏｕｐ＞リソースの既存の＜ｆａｎｏｕｔＰｏｉｎｔ＞を対象とするリクエストが、ＤＳＬＴとして処理されるべきか否か検出するために、リクエスト内の１つまたは複数のＤＳＬＴ関連パラメータの存在に依存してよい。

（ｏｎｅＭ２Ｍロック属性）
全てのｏｎｅＭ２Ｍリソースに、追加のｏｎｅＭ２Ｍ「ｌｏｃｋ」共通属性が使用されてよい。この新しい属性は、リソースがロック状態かどうかを追跡し、かつ通知するために、ホスティングＣＳＥによって使用されてよい。例えば、ＤＳＬＴが処理されるときに、そのターゲットリソースはロックされてよい。ロックされると、ロック属性は、リソースがロックされたことを反映するために更新されてよい。この属性は、ｔｒｕｅまたはｆａｌｓｅなどの値で構成されてよい。あるいは、この属性は、様々なタイプのロック（例えば、更新のためのみにロックされるなど）に反映する値をサポートしてもよい。

（ｏｎｅＭ２Ｍ ＤＳＬＴ識別子）
ＤＳＬＴ機能をサポートするために、ｏｎｅＭ２Ｍ ＤＳＬＴ識別子が使用されてよい。個々のＤＳＬＴリクエストの処理には、それぞれが固有の異なるｏｎｅＭ２Ｍリクエスト識別子を有する複数のｏｎｅＭ２Ｍリクエストを必要とする場合があるので、ＤＳＬＴ識別子は、これらの別々のｏｎｅＭ２Ｍリクエストを単一のＤＳＬＴに関連付けるメカニズムを提供する。この関連付けのレベルにより、ＤＳＬＴを構成する個々のｏｎｅＭ２Ｍリクエストの、分散され、かつ原子的処理を可能にする。表１１は、ｏｎｅＭ２Ｍ ＤＳＬＴ識別子フォーマットの説明である。表１２は、ｏｎｅＭ２Ｍ ＤＳＬＴベースのリクエスト識別子の構成の説明である。

ＤＳＬＴシーケンス機能をサポートするために、ＤＳＬＴシーケンス用のｏｎｅＭ２Ｍ識別子について記載する。ＤＳＬＴシーケンスの処理には複数のＤＳＬＴの処理を必要とする場合があり、各ＤＳＬＴの処理にはそれぞれが固有の異なるｏｎｅＭ２Ｍリクエスト識別子を有する複数のｏｎｅＭ２Ｍリクエストの処理を必要とする場合があるので、ＤＳＬＴシーケンス識別子は、これらの複数のＤＳＬＴおよびｏｎｅＭ２Ｍリクエストを単一のＤＳＬＴシーケンスに関連付けるメカニズムを提供する。この関連付けのレベルにより、ＤＳＬＴシーケンスを構成する個々のＤＳＬＴおよびｏｎｅＭ２Ｍリクエストの、分散され、かつ原子的処理を可能にする。表１３は、ｏｎｅＭ２Ｍ ＤＳＬＴシーケンス識別子フォーマットの説明である。表１４は、ｏｎｅＭ２Ｍ ＤＳＬＴシーケンスベースのＤＳＬＴ識別子の構成の説明である。表１５は、ｏｎｅＭ２Ｍ ＤＳＬＴシーケンスベースのリクエスト識別子の構成の説明である。

（ｏｎｅＭ２Ｍ ＤＳＬＴグループファンアウトプロシージャ）
図２７－１および２７－２は、ｏｎｅＭ２Ｍ ＤＳＬＴグループファンアウトプロシージャを示す図である。

図２７－１および２７－２のステップ１では、ｏｎｅＭ２Ｍ＜ｇｒｏｕｐ＞リソースが生成される。グループのメンバーは、ＡＳＮ－ＣＳＥ１およびＡＳＮ－ＣＳＥ２でホストされるコンテナリソースとなるように構成される。このグループはＤＳＬＴ－ＴＦ１２０２をホストしているＡＥまたはシステム内の別のＡＥによって生成されてよい。

図２７－１および２７－２のステップ２では、ＤＳＬＴ－ＴＦ１２０２機能をホストしているＡＥは、ＡＳＮ－ＣＳＥ１およびＡＳＮ－ＣＳＥ２によってホストされているコンテナリソースに属するｏｎｅＭ２Ｍ＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を原子的に生成するためにｏｎｅＭ２Ｍ ＤＳＬＴリクエストを構築する。このＤＳＬＴリクエストは、図２７－１および２７－２に示すように、ｏｎｅＭ２Ｍ＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞ＣＲＥＡＴＥプリミティブとして構成されてよい。あるいは、このＤＳＬＴリクエストは、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞ＣＲＥＡＴＥプリミティブをそのプリミティブ属性内にカプセル化するｏｎｅＭ２Ｍ＜ｔｒａｎｓａｃｔｉｏｎ＞ＣＲＥＡＴＥリクエストプリミティブとして構成されてもよい。図２７－１および２７－２には示されていないが、リクエストは、同様に、いつ操作を実施するかのスケジュール、実行基準のセット、優先順位、トランザクションの処理の試みが失敗した場合の再試行の回数、および完了基準のセットなどの追加のパラメータを含んでよい。

図２７－１および２７－２のステップ３では、ＤＳＬＴ－ＴＦ１２０２機能をホストしているＡＥは、ＤＳＬＴ－ＭＦ１２０４性能をサポートしているＩＮ－ＣＳＥ２７０２にＤＳＬＴリクエストを送信する。リクエストは、ＩＮ－ＣＳＥ２７０２がメンバーにリクエストを原子的に配布することによってリクエストを処理できるようにステップ１で生成されたグループリソースの＜ｔｒａｎｓａｃｔｉｏｎＦａｎＯｕｔＰｏｉｎｔ＞子リソースに送信される。このリクエストは、新しいタイプのｏｎｅＭ２Ｍ非ブロッキングリクエストである非ブロッキングトランザクションリクエストを使用して送信されてよい。このリクエストでは、非ブロッキングリクエストの処理が完了したときに通知する際にＩＮ－ＣＳＥ２７０２が使用することになる通知コールバックＵＲＩをＡＥが規定してよい。あるいは、ＡＥは代わりにブロッキングリクエストを使用することもできる。

図２７－１および２７－２のステップ４では、ＩＮ－ＣＳＥ２７０２はＤＳＬＴリクエストを受信する。リクエストが非ブロッキングトランザクションとして送信される場合、ＩＮ－ＣＳＥ２７０２は、トランザクション指向属性をサポートし、かつ状態属性を「Ｉｎｉｔｉａｌ」と構成するｏｎｅＭ２Ｍ＜ｒｅｑｕｅｓｔ＞リソースを生成する。この＜ｒｅｑｕｅｓｔ＞リソースは、ＤＳＬＴを処理している間に、ＤＳＬＴリクエストリソースを追跡するために、ＩＮ－ＣＳＥ２７０２によって使用されてよい。

図２７－１および２７－２のステップ５では、ＩＮ－ＣＳＥ２７０２は、リクエストを受信して処理を開始したことを示す応答をＡＥに返す。あるいは、リクエストはブロッキング式に処理されてもよい。

図２７－１および２７－２のステップ６では、ＩＮ－ＣＳＥ２７０２は、次にグループトランザクションファンアウト性能を使用してＤＳＬＴを処理する。

図２７－１および２７－２のステップ７では、ＩＮ－ＣＳＥ２７０２は、グループメンバーリソースがＩＮ－ＣＳＥ２７０２でローカルにホストされていないことを検出する。その後、ＩＮ－ＣＳＥ２７０２は対応するＤＳＬＴリクエスト（すなわち、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞ＣＲＥＡＴＥプリミティブ）を準備し、これらのターゲットデバイスに配布（すなわち、ファンアウト）する。このＤＳＬＴは、図２７－１および２７－２に示すように、非ブロッキングｏｎｅＭ２Ｍ＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞ＣＲＥＡＴＥプリミティブとして構成されてよい。あるいは、このＤＳＬＴリクエストは、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞ＣＲＥＡＴＥプリミティブをそのプリミティブ属性内にカプセル化するｏｎｅＭ２Ｍ＜ｔｒａｎｓａｃｔｉｏｎ＞ＣＲＥＡＴＥリクエストプリミティブとして構成されてもよい。

図２７－１および２７－２のステップ８では、ＡＳＮ－ＣＳＥ２７０４および１２０６のＤＳＬＴ－ＣＦ１２０８および１２１０は、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を生成するＤＳＬＴをそれぞれ受信して、＜ｒｅｑｕｅｓｔ＞（あるいは＜ｔｒａｎｓａｃｔｉｏｎ＞）リソースを生成することによってリクエストを処理し、ＤＳＬＴを処理している間、トランザクション状態を追跡する。ＡＳＮ－ＣＳＥ２７０４および２７０６は、ＤＳＬＴに含まれるトランザクション情報を用いてこのリソースの状態を構成する。ＡＳＮ－ＣＳＥ２７０４および２７０６は、まず、ターゲットリソースの利用可能性をチェックすることによってトランザクションの処理を開始する。ＡＳＮ－ＣＳＥ２７０４および２７０６は、規定操作を実施するためのリソースの利用可能性、ならびに現時点でリソースを予約およびロックしている他のトランザクションがないことをチェックする。リソースが利用可能な場合、ＡＳＮ－ＣＳＥ２７０４および２７０６は、現在のトランザクションの処理中に届く可能性のある他のトランザクションからの干渉を受けることなく、該リソースでトランザクションを実施できるようにリソースをロックする。

図２７－１および２７－２のステップ９では、ＡＳＮ－ＣＳＥ２７０４および２７０６は、ＤＳＬＴが受信されて、トランザクションで処理が開始して、ターゲットリソースが利用可能であり、他のトランザクションから干渉を受けることなく現在のトランザクションが進行できるようにリソースがロックされたことを示すステータスをＩＮ－ＣＳＥ２７０２に返す。

図２７－１および２７－２のステップ１０では、ＩＮ－ＣＳＥ２７０２は、全てのメンバーがターゲットリソースを正常にロックしたと応答したことを検出する。その結果、ＩＮ－ＣＳＥ２７０２は、トランザクションを実行するように、ターゲットメンバーに続いて命令してよいと判断する。

図２７－１および２７－２のステップ１１では、ＩＮ－ＣＳＥ２７０２は、トランザクションに関連付けられたその対応する＜ｒｅｑｕｅｓｔ＞リソース内のコマンド属性を更新するように各ＡＳＮ－ＣＳＥ２７０４および２７０６にリクエストを送信する。コマンド属性は、値「Ｅｘｅｃｕｔｅ」に更新される。あるいは、このコマンド属性は、＜ｔｒａｎｓａｃｔｉｏｎ＞リソースの属性であってもよい。

図２７－１および２７－２のステップ１２では、トランザクションの実行のコマンドを受信すると、各ＡＳＮ－ＣＳＥ２７０４および２７０６は、ターゲットリソースでトランザクションに規定された操作を実施する。

図２７－１および２７－２のステップ１３では、一旦、実行が完了すると、各ＡＳＮ－ＣＳＥ２７０４および２７０６は、実行結果、およびそれが成功したか否かと共に、ＩＮ－ＣＳＥ２７０２に応答を返す。

図２７－１および２７－２のステップ１４では、ＩＮ－ＣＳＥ２７０２は、全てのグループメンバーがターゲットリソースでトランザクションを正常に実行したと応答したことを検出する。その結果、ＩＮ－ＣＳＥ２７０２は、結果（例えば、更新されたリソース表現）を耐久的なものにし、かつリソースおよびその更新済み状態に他のトランザクションがアクセスできるようにリソースのロックを解放することによって結果をコミットするように、メンバーに続いて命令してよいと判断する。

図２７－１および２７－２のステップ１５では、ＩＮ－ＣＳＥ２７０２は、各グループメンバーにリクエストを送信して、トランザクションをコミットするようにコマンドする。このコマンドは、ＩＮ－ＣＳＥ２７０２によって発行されてよく、各ＡＳＮ－ＣＳＥ２７０４および２７０６でホストされている＜ｒｅｑｕｅｓｔ＞（あるいは＜ｔｒａｎｓａｃｔｉｏｎ＞）リソース内のコマンド属性を更新し、トランザクションをコミットするように命令する。

図２７－１および２７－２のステップ１６では、トランザクションをコミットするコマンドを受信すると、各ＡＳＮ－ＣＳＥ２７０４および２７０６は、トランザクション実行時に行われた可能性のあるリソースへのいずれの更新もその状態が耐久的なものとなるように保存する。次に、ＡＳＮ－ＣＳＥ２７０４および２７０６はターゲットリソースのいずれのロックも解放する。

図２７－１および２７－２のステップ１７では、一旦、コミットが完了すると、各ＡＳＮ－ＣＳＥ２７０４および２７０６は、コミット結果、およびそれが成功したか否かと共に、ＩＮ－ＣＳＥ２７０２に応答を返す。

図２７－１および２７－２のステップ１８では、ＩＮ－ＣＳＥ２７０２は、全てのグループメンバー（すなわち、ＡＳＮ－ＣＳＥ２７０４および２７０６の両方）がターゲットリソースでトランザクションを正常にコミットしたと応答したことを検出する。

図２７－１および２７－２のステップ１９では、ＩＮ－ＣＳＥ２７０２は、ＡＥから受信したＤＳＬＴに対応する、そのローカルにホストされている＜ｒｅｑｕｅｓｔ＞リソースを更新する。この更新には、グループメンバーに配布して、トランザクションが成功したかどうか、および成功しなかった場合はその失敗の原因または理由を示すＤＳＬＴのそれぞれのステータスが含まれる。

図２７－１および２７－２のステップ２０では、一旦、ＤＳＬＴ処理が完了すると、ＩＮ－ＣＳＥ２７０２は、ＡＥにＤＳＬＴの結果を含めて通知してよい。ＩＮ－ＣＳＥ２７０２は、ＤＳＬＴの全体的なステータスおよび個々のターゲットで実施された各配布されたトランザクションの個々のステータスを含めてよい。これには、失敗の原因を説明するエラーまたはデバッグ情報を含んでよい。これにより、技術者およびオペレータは、問題を検出して、別のＤＳＬＴの発行を再試行する前に障害のあるデバイスを交換または修復できる。

図２７－１および２７－２のステップ２１では、完了したＤＳＬＴの通知の受信後、ＡＥは、ＩＮ－ＣＳＥ２７０２に、通知受信の確認を応答してよい。

図２７－１および２７－２のステップ２２では、いずれかの時点で、ＡＥがＤＳＬＴ処理のステータスのチェックを所望する場合、ＩＮ－ＣＳＥ２７０２がホストしている＜ｒｅｑｕｅｓｔ＞リソースに、ステータスをチェックするように問い合わせしてよい。問い合わせリクエストを受信すると、ＩＮ－ＣＳＥ２７０２は、このリソース内で保持されているＤＳＬＴの状態をチェックしてよい。

図２７－１および２７－２のステップ２３では、ＩＮ－ＣＳＥ２７０２は、ＡＥにＤＳＬＴ処理の状態を返す。

（ｏｎｅＭ２Ｍ ＤＳＬＴシーケンスプロシージャ）
図２８－１および２８－２は、ｏｎｅＭ２Ｍ ＤＳＬＴシーケンスプロシージャを示す図である。

図２８－１および２８－２のステップ１は、任意のステップである。図２８－１および２８－２のステップ１では、１つまたは複数のｏｎｅＭ２Ｍ ＤＳＬＴまたはＤＳＬＴシーケンスポリシーリソースが生成される。これらリソースは、ＤＳＬＴ－ＴＦ１２０２をホストしているＡＥまたはシステム内の別のＡＥによって生成されてよい。各ポリシーリソースは、ＩＮ－ＣＳＥ２７０２によってホストされているＤＳＬＴ－ＭＦ１２０４がＤＳＬＴシーケンスリクエストをどのように処理するかを制御するための１つまたは複数のルールを含んでよい。これらのルールは、ＤＳＬＴシーケンススケジューリング、ＤＳＬＴシーケンスの再試行、ＤＳＬＴシーケンスの優先順位付け、ならびに、ＤＳＬＴシーケンス向けの実行基準および完了基準に関連してよい。あるいは、ＩＮ－ＣＳＥ２７０２は、ＤＳＬＴシーケンスポリシーを用いて事前にプロビジョンされてもよい。

図２８－１および２８－２のステップ２では、ＤＳＬＴ－ＴＦ１２０２機能をホストしているＡＥは、ＡＳＮ－ＣＳＥ２７０４および２７０６によってホストされているコンテナリソースに属する一連のｏｎｅＭ２Ｍ＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を原子的に生成するために、ｏｎｅＭ２Ｍ ＤＳＬＴシーケンスリクエストを構築する。このＤＳＬＴシーケンスリクエストは、ｏｎｅＭ２Ｍ＜ｓｅｑｕｅｎｃｅ＞ＣＲＥＡＴＥプリミティブとして構成されてよい。＜ｓｅｑｕｅｎｃｅ＞リソースは、一連の＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞ＣＲＥＡＴＥプリミティブをそのトランザクション属性内にカプセル化する。各＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞ＣＲＥＡＴＥプリミティブは、ＡＳＮ－ＣＳＥ２７０４および２７０６によってホストされるコンテナリソースとなるように構成されるそのメンバー属性を有するＩＮ－ＣＳＥ２７０２でホストされているグループリソースを対象としてよい。したがって、各＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞ＣＲＥＡＴＥプリミティブは、シーケンス内の別々のトランザクションである。図２７－１および２７－２には示されていないが、個々の＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞ＣＲＥＡＴＥプリミティブは、代わりに、ＩＮ－ＣＳＥ２７０２で別々の＜ｔｒａｎｓａｃｔｉｏｎ＞リソースとして生成されてもよい。＜ｓｅｑｕｅｎｃｅ＞リソースのトランザクション属性は、これらの個々の＜ｔｒａｎｓａｃｔｉｏｎ＞リソースを参照する識別子のリストによって構成されてよい。＜ｓｅｑｕｅｎｃｅ＞ＣＲＥＡＴＥプリミティブは、同様に、いつシーケンスを実施するかのスケジュール、実行基準のセット、優先順位、シーケンスの処理が失敗した場合に試みる再試行の回数、および完了基準のセットなどの追加のパラメータを含んでよい。

図２８－１および２８－２のステップ３では、ＤＳＬＴ－ＴＦ１２０２機能をホストしているＡＥは、ＤＳＬＴ－ＭＦ１２０４性能をサポートしているＩＮ－ＣＳＥ２７０２にＤＳＬＴシーケンスリクエストを送信する。このリクエストは、ブロッキングまたは非ブロッキングリクエストを使用してＩＮ－ＣＳＥ２７０２に送信されてよい。非ブロッキングリクエストが使用される場合、ＡＥは、非ブロッキングリクエストの処理が完了したときに通知する際にＩＮ－ＣＳＥ２７０２が使用することになる通知コールバックＵＲＩを規定してよい。あるいは、ＡＥは、ブロッキングリクエストまたは代わりに既存のｏｎｅＭ２Ｍ非ブロッキングリクエストのうち１つを使用できる。

図２８－１および２８－２のステップ４では、ＩＮ－ＣＳＥ２７０２はＤＳＬＴシーケンスリクエストを受信する。

図２８－１および２８－２のステップ５では、ＩＮ－ＣＳＥ２７０２は、リクエストを受信して処理を開始したことを示す応答をＡＥに返す。あるいは、リクエストはブロッキング式に処理されてもよい。図には示されていないが、＜ｓｅｑｕｅｎｃｅ＞リソースに変更（例えば、シーケンスの状態の更新）が生じるときにＩＮ－ＣＳＥ２７０２から通知を受信するために、ＡＥは＜ｓｅｑｕｅｎｃｅ＞リソースにサブスクリプションを生成してもよい。

図２８－１および２８－２のステップ６では、次に、ＩＮ－ＣＳＥ２７０２は、ＤＳＬＴシーケンスの処理を開始する。

図２８－１および２８－２のステップ７では、ＩＮ－ＣＳＥ２７０２は、リクエストを解析し、シーケンス内の最初のＤＳＬＴを入手する。ＩＮ－ＣＳＥ２７０２は、このＤＳＬＴがＡＳＮ－ＣＳＥ２７０４および２７０６でホストされているコンテナであるメンバーリソースで構成されるグループリソースを対象としていることを検出する。その後、ＩＮ－ＣＳＥ２７０２は対応するＤＳＬＴリクエスト（すなわち、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞ＣＲＥＡＴＥプリミティブ）を準備し、これらのターゲットデバイスに配布（すなわち、ファンアウト）する。このＤＳＬＴは、図２７－１および２７－２に示すように、非ブロッキングｏｎｅＭ２Ｍ＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞ＣＲＥＡＴＥプリミティブとして構成されてよい。あるいは、ＤＳＬＴリクエストは、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞ＣＲＥＡＴＥプリミティブをそのプリミティブ属性内にカプセル化するｏｎｅＭ２Ｍ＜ｔｒａｎｓａｃｔｉｏｎ＞ＣＲＥＡＴＥリクエストプリミティブとして構成されてもよい。

図２８－１および２８－２のステップ８では、ＩｏＴデバイス１２３４および１２３６のＤＳＬＴ－ＣＦ１２０８および１２１０は、それぞれのＤＳＬＴ－ＲＥＱを受信する。どちらともリクエストを処理し、ローカルＤＳＬＴリソースを生成して、ＤＳＬＴを処理している間、トランザクションの状態を追跡する。ＤＳＬＴ－ＣＦは、ＤＳＬＴ－ＲＥＱパラメータ内に含まれている情報を用いてそれらのリソースの属性を構成する。ＤＳＬＴ－ＣＦは、まず、ターゲットリソースの利用可能性をチェックすることによってトランザクションの処理を開始する。リソースがＩｏＴデバイスに対してローカルの場合、ＤＳＬＴ－ＣＦ１２１０は、規定操作を実施するためのリソースの利用可能性、ならびに現時点でリソースを予約およびロックしている他のトランザクションがないことをチェックする。リソースが利用可能な場合は、ＤＳＬＴ－ＣＦは、現在のトランザクションの処理中に届く可能性のある他のトランザクションからの干渉を受けることなく、該リソースでトランザクションを実施してもよいようにリソースをロックしてよい。ＤＳＬＴ－ＣＦ１２１０がＤＳＬＴ－ＲＥＱを受信して、リクエストがローカルデバイスでホストされていないリソースを対象としていることを見つける場合、ＤＳＬＴ－ＣＦは、（場合によっては、デバイスでローカルにホストされているＤＳＬＴ－ＭＦ１２０４の支援を用いて）その他のデバイスのＤＳＬＴ－ＣＦ１２０８がそれを処理してもよいように、システム内の別のデバイスに向けてＤＳＬＴ－ＲＥＱを再対象としてよい。

ＡＳＮ－ＣＳＥ２７０４および２７０６のＤＳＬＴ－ＣＦは、＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞を生成するＤＳＬＴをそれぞれ受信し、＜ｒｅｑｕｅｓｔ＞（あるいは＜ｔｒａｎｓａｃｔｉｏｎ＞）リソースを生成することによってリクエストを処理して、ＤＳＬＴを処理している間、トランザクション状態を追跡する。ＡＳＮ－ＣＳＥ２７０４および２７０６は、ＤＳＬＴに含まれるトランザクション情報を用いてこのリソースの状態を構成する。ＡＳＮ－ＣＳＥ２７０４および２７０６は、まず、ターゲットリソースの利用可能性をチェックすることによってトランザクションの処理を開始する。ＡＳＮ－ＣＳＥ２７０４および２７０６は、規定操作を実施するためのリソースの利用可能性、ならびに現時点でリソースを予約およびロックしている他のトランザクションがないことをチェックする。リソースが利用可能な場合、ＡＳＮ－ＣＳＥ２７０４および２７０６は、現在のトランザクションの処理中に届く可能性のある他のトランザクションからの干渉を受けることなく、該リソースでトランザクションを実施できるようにリソースをロックする。

図２８－１および２８－２のステップ９では、ＡＳＮ－ＣＳＥ２７０４および２７０６は、ＤＳＬＴが受信されて、トランザクションで処理が開始して、ターゲットリソースが利用可能であり、他のトランザクションから干渉を受けることなく現在のトランザクションが進行できるようにリソースがロックされたことを示すステータスをＩＮ－ＣＳＥ２７０２に返す。

図２８－１および２８－２のステップ１０では、ＩＮ－ＣＳＥ２７０２は、全てのメンバーがターゲットリソースを正常にロックしたと応答したことを検出する。その結果、ＩＮ－ＣＳＥ２７０２は、トランザクションを実行するように、ターゲットメンバーに続いて命令してよいと判断する。

図２８－１および２８－２のステップ１１では、ＩＮ－ＣＳＥ２７０２は、トランザクションに関連付けられたその対応する＜ｒｅｑｕｅｓｔ＞リソース内のコマンド属性を更新するように各ＡＳＮ－ＣＳＥにリクエストを送信する。コマンド属性は、値「Ｅｘｅｃｕｔｅ」に更新される。あるいは、このコマンド属性は、＜ｔｒａｎｓａｃｔｉｏｎ＞リソースの属性であってもよい。

図２８－１および２８－２のステップ１２では、トランザクションの実行のコマンドを受信すると、各ＡＳＮ－ＣＳＥ２７０４および２７０６は、ターゲットリソースでトランザクションに規定された操作を実施する。

図２８－１および２８－２のステップ１３では、一旦、実行が完了すると、各ＡＳＮ－ＣＳＥ２７０４および２７０６は、実行結果、およびそれが成功したか否かと共に、ＩＮ－ＣＳＥ２７０２に応答を返す。

図２８－１および２８－２のステップ１４では、ＩＮ－ＣＳＥ２７０２は、全てのターゲットメンバー（すなわち、ＡＳＮ－ＣＳＥ２７０４および２７０６）がターゲットリソースでトランザクションを正常に実行したと応答したことを検出する。次いで、ＩＮ－ＣＳＥ２７０２は、シーケンス内に残存するＤＳＬＴがあるかどうかをチェックする。残存するＤＳＬＴがある場合、ＩＮ－ＣＳＥ２７０２は、次のＤＳＬＴを準備して、ステップ７～１４を繰り返す。シーケンス内に残存するＤＳＬＴがない場合、ＩＮ－ＣＳＥ２７０２は、結果を耐久的なものにし、かつリソースおよび更新済み状態に他のトランザクションがアクセスできるようにリソースのロックを解放することによって、シーケンスの一部として処理された全てのＤＳＬＴの結果をコミットするように、メンバーに続いて命令してよいと判断する。

図２８－１および２８－２のステップ１５では、ＩＮ－ＣＳＥ２７０２は、各ＤＳＬＴが実行されたＡＳＮ－ＣＳＥ２７０４および２７０６に一連のコミットリクエストを送信する。各コマンドは、ＩＮ－ＣＳＥ２７０２によって発行されてよく、各ＡＳＮ－ＣＳＥ２７０４および２７０６でホストされている＜ｒｅｑｕｅｓｔ＞（あるいは＜ｔｒａｎｓａｃｔｉｏｎ＞）リソース内のコマンド属性を更新し、対応するトランザクションをコミットするように命令する。

図２８－１および２８－２のステップ１６では、所定のＤＳＬＴをコミットする各コマンドを受信すると、各ＡＳＮ－ＣＳＥ２７０４および２７０６は、トランザクション実行時に行われた可能性のあるリソースへのいずれの更新もその状態が耐久的なものとなるように保存する。コミットされるリソースの状態のいずれの更新にも基づいて、ターゲットリソースにサブスクライブした可能性のあるシステム内のいずれの他のエンティティにも更新状態に関する通知を送信してもよい。次いで、各ＡＳＮ－ＣＳＥ２７０４および２７０６は、ターゲットリソースのいずれのロックも解放し、保存した操作前状態のいずれも削除してよい。

図２８－１および２８－２のステップ１７では、一旦、各コミットが完了すると、各ＡＳＮ－ＣＳＥ２７０４および２７０６は、コミット結果、およびそれが成功したか否かと共に、ＩＮ－ＣＳＥ２７０２に応答を返す。

図２８－１および２８－２のステップ１８では、ＩＮ－ＣＳＥ２７０２は、それぞれのターゲットＡＳＮ－ＣＳＥ２７０４および２７０６が、それぞれのターゲットリソースでシーケンス内の全てのトランザクションを正常にコミットしたと応答したことを検出する。

図２８－１および２８－２のステップ１９では、ＩＮ－ＣＳＥ２７０２は、自身のローカルにホストされているＤＳＬＴシーケンスリソースを更新する。この更新には、配布されたシーケンス内のＤＳＬＴのそれぞれのステータスが含まれる。このステータスは、トランザクションシーケンスが成功したかどうかを示し、成功しなかった場合はその失敗の理由を示す。ＩＮ－ＣＳＥ２７０２は、シーケンス内の失敗したいずれのＤＳＬＴの個々のステータスおよび失敗の情報も含めてもよい。

図２８－１および２８－２のステップ２０では、一旦、ＤＳＬＴシーケンス処理が完了すると、ＩＮ－ＣＳＥ２７０２は、ＡＥにＤＳＬＴシーケンスの結果を含めて通知してよい。ＩＮ－ＣＳＥ２７０２は、ＤＳＬＴシーケンスの全体的なステータスおよび個々のターゲットで実施されたシーケンス内の各配布されたトランザクションの個々のステータスを含めてよい。これは、失敗の原因を説明するエラーまたはデバッグ情報を含んでよい。これにより、技術者およびオペレータは、問題を検出して、別のＤＳＬＴの発行を再試行する前に障害のあるデバイスを交換または修復できる。

図２８－１および２８－２のステップ２１では、完了したＤＳＬＴシーケンスの通知の受信後、ＡＥは、ＩＮ－ＣＳＥ２７０２に、通知受信の確認を応答してよい。

図２８－１および２８－２のステップ２２では、いずれかの時点で、ＡＥがＤＳＬＴシーケンス処理のステータスのチェックを所望する場合、ＩＮ－ＣＳＥ２７０２にステータスをチェックするように問い合わせしてよい。問い合わせリクエストを受信すると、ＩＮ－ＣＳＥ２７０２は、対応するＤＳＬＴシーケンスリソース内で保持しているＤＳＬＴシーケンスリソースの状態をチェックしてよい。

図２８－１および２８－２のステップ２３では、ＤＳＬＴ－ＭＦ１２０４は、ＤＳＬＴステータス問い合わせを開始したＤＳＬＴ－ＴＦ１２０２にＤＳＬＴシーケンス処理の状態を返す。

（分散サービス層トランザクションユーザーインターフェース）
グラフィカルユーザーインターフェース（Graphical User Interface：ＧＵＩ）などのインターフェースを使用して、ユーザーが分散トランザクション管理に関連した機能を制御および／または構成することを支援してよい。図２９に示すようなインターフェース２９０２、２９０４、２９０６および２９０８などのユーザーインターフェースを実装して、リクエストが原子的に実施されるような複数のＩｏＴデバイスへのＤＳＬＴベースのリクエストをユーザーが開始できるようにしてもよい。例えば、組立ライン展開などの調整された方式で動作するデバイスのセット上の、制御設定の原子的な更新を実施することなどが挙げられる。受信するＤＳＬＴをどう処理するかを制御するために、デバイス、ゲートウェイ、サーバおよびアプリケーション内のＤＳＬＴ関連ポリシーを構成するためにもユーザーインターフェースを実装してよい。インターフェース２９０２、２９０４、２９０６および２９０８は、図３０Ｃ～Ｄに示し、以下で述べるようなディスプレイを使用して作られてよいことを理解されたい。

（Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システムの例）
本明細書に記載されている種々の技術は、ハードウェア、ファームウェア、ソフトウェアまたは適切な場合にこれらの組み合わせと連携して実装されてもよい。かかるハードウェア、ファームウェア、およびソフトウェアは、通信ネットワークの種々のノードで配置される装置に含まれてもよい。本明細書記載の方法を行うために、装置は単独でまたは互いに連携して動作してもよい。本明細書において、用語「装置」、「ネットワーク装置」、「ノード」、「デバイス」、および「ネットワークノード」は同じ意味で用いられる場合がある。

サービス層は、ネットワークサービスアーキテクチャ内の機能層であってよい。サービス層は、典型的には、ＨＴＴＰ、ＣｏＡＰまたはＭＱＴＴなどのアプリケーションプロトコル層の上位に位置し、クライアントアプリケーションに付加価値サービスを提供する。サービス層は、例えば、コントロール層およびトランスポート層／アクセス層などの下位リソース層のコアネットワークにインターフェースも提供する。サービス層は、サービス定義、サービス実行時間有効化、ポリシー管理、アクセス制御、およびサービスクラスタ化を含む（サービス）性能または機能の複数のカテゴリーをサポートする。近年、いくつかの業界規格団体、例えば、ｏｎｅＭ２Ｍが、インターネット／ウェブ、セルラー、企業ネットワーク、およびホームネットワークなどの展開へのＭ２Ｍタイプのデバイスおよびアプリケーションの統合に関連する課題に対処するためにＭ２Ｍサービス層を開発している。Ｍ２Ｍサービス層は、ＣＳＥまたはＳＣＬと呼ばれることもあるサービス層によってサポートされる上述の性能または機能の集合またはセットへのアクセスをアプリケーションおよび／または種々のデバイスに提供することができる。いくつかの例としては、種々のアプリケーションによって一般に使用されることがある、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、および接続性管理が挙げられるが、これらに限定されない。これらの性能または機能は、Ｍ２Ｍサービス層によって定義されるメッセージフォーマット、リソース構造、およびリソース表現を利用するＡＰＩを介して、そのような種々のアプリケーションが利用できるものである。ＣＳＥまたはＳＣＬは、ハードウェアおよび／またはソフトウェアによって実装可能であり、それらがそのような性能もしくは機能を使用するために、種々のアプリケーションおよび／またはデバイス（すなわち、そのような機能エンティティ間の機能インターフェース）で具現化される（サービス）性能もしくは機能を提供する機能エンティティである。

図３０Ａは、１つまたは複数の開示する実施形態がその中で実装される可能性のある、Ｍ２Ｍ（machine-to-machiine）、ＩｏＴ（Internet of Things）、またはＷｏＴ（Web of Things）通信システム１０の例の図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構築ブロックを提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントまたはノード、ならびにＩｏＴ／ＷｏＴサービス層などであってよい。通信システム１０は、開示される実施形態の機能を実装するために使用されてよく、機能、ならびにＤＳＬＴ－ＴＦ１２０２、ＤＳＬＴ－ＭＦ１２０４および１２０６、ＤＳＬＴ－ＣＦ１２０８、１２１０、１２１２および１２１４、ＤＳＬＴ－ＭＦ ＡＰＩ１３０２、ＤＳＬＴ－ＭＦ処理１３０４、ＤＳＬＴ－ＭＦシーケンス処理１３０６、ＤＳＬＴ－ＭＦポリシーエンジン１３０８、ＤＳＬＴ－ＭＦスケジューラ１３１０、ＤＳＬＴ－ＣＦ ＡＰＩ１４０２、ＤＳＬＴ－ＣＦ処理１４０４、ＤＳＬＴ－ＣＦシーケンス処理１４０６、ＤＳＬＴ－ＭＦ ＣＳＦ２３０４、サービス層１０２、アプリケーションプロトコル１０４、アプリケーション１０６、ＣＳＥ３０２、３０６および２３０２、ＡＥ３０４、７０４、７０６、７０８および２３０６、ＮＳＥ３０８、ＩｏＴアプリケーション１００２および１２３０、ＩｏＴデバイス１００４、１００６、１００８、１２３４、１２３６、１２３８および１２４０、ＩｏＴサーバ１１０２および１２３２、ＩｏＴゲートウェイ１２４２、ＩＮ－ＣＳＥ２７０２、ＡＳＮ－ＣＳＥ２７０４および２７０６、および、インターフェース２９０２、２９０４、２９０６および２９０８などのインターフェースを作る論理的エンティティなどの論理的エンティティを含んでもよい。

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

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

例示的Ｍ２Ｍ端末デバイス１８としては、タブレット、スマートフォン、メディカルデバイス、気温・天候モニター、コネクテッドカー、スマートメーター、ゲームコンソール、携帯情報端末、健康・フィットネスモニター、照明、サーモスタット、機器、ガレージドアおよびアクチュエータ式のデバイス、セキュリティデバイスおよびスマートコンセントなどが挙げられるが、これらに限定されない。

図３０Ｂを参照すると、図示されているフィールドドメイン内のＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８、ならびに通信ネットワーク１２にサービスを提供する。Ｍ２Ｍサービス層２２は、例えば、以下で説明され、図３０Ｃおよび３０Ｄに図示されるデバイスなどを含む、１つまたは複数のサーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウド／ストレージファームなど）などによって、実装されてよい。Ｍ２Ｍサービス層２２は、所望により、任意数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信してよい。Ｍ２Ｍサービス層２２は、サーバ、コンピュータ、デバイスなどを含むことがある、ネットワークの１つまたは複数のノードによって実装されてよい。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイ１４およびＭ２Ｍアプリケーション２０に適用するサービス性能を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで、など様々な方法で実装されてよい。

図示されているＭ２Ｍサービス層２２に類似したＭ２Ｍサービス層２２’がインフラストラクチャドメイン内に存在する。Ｍ２Ｍサービス層２２’は、インフラストラクチャドメイン内のＭ２Ｍアプリケーション２０’および下位通信ネットワーク１２にサービスを提供する。Ｍ２Ｍサービス層２２’は、フィールドドメイン内のＭ２Ｍゲートウェイ１４およびＭ２Ｍ端末デバイス１８にもサービスを提供する。Ｍ２Ｍサービス層２２’は、任意の数のＭ２Ｍアプリケーション、Ｍ２ＭゲートウェイおよびＭ２Ｍデバイスと通信してよい。Ｍ２Ｍサービス層２２’は、異なるサービスプロバイダによるサービス層と相互作用してもよい。Ｍ２Ｍサービス層２２’は、サーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウドコンピューティング／ストレージファームなど）を含むネットワークの１つまたは複数のノードによるものである。

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

本発明の方法は、サービス層２２および２２’の一部として実装されてもよい。サービス層２２および２２’は、アプリケーションプログラミングインターフェース（ＡＰＩ）と下位ネットワークインターフェースとのセットを介して付加価値サービス能力をサポートするソフトウェアミドルウェア層である。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍの両方では、本出願の接続方法を含む可能性のあるサービス層を使用する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス性能層（Service Capability Layer：ＳＣＬ）と称される。ＳＣＬは、Ｍ２Ｍデバイス（この場合、デバイスＳＣＬ（Device SCL：ＤＳＣＬ）と称される）、ゲートウェイ（この場合、ゲートウェイＳＣＬ（Gateway SCL：ＧＳＣＬ）と称される）、および／またはネットワークノード（この場合、ネットワークＳＣＬ（Network SCL：ＮＳＣＬ）と称される）内に実装される可能性がある。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス性能）のセットをサポートする。１つまたは複数の特定のタイプのＣＳＦのセットのインスタンス化は、種々のタイプのネットワークノード（例えば、インフラストラクチャノード、ミドルノード、アプリケーション固有ノード）でホストされる可能性のある共通サービスエンティティ（ＣＳＥ）と称される。さらに、本願の接続方法は、本願の接続方法などのサービスにアクセスするために、サービス指向アーキテクチャ（Service Oriented Architecture：ＳＯＡ）および／またはリソース指向アーキテクチャ（Resource-Oriented Architecture：ＲＯＡ）を使用するＭ２Ｍネットワークの一部として実装することができる。

一部の実施形態では、Ｍ２Ｍアプリケーション２０および２０’は、開示したシステムおよび方法と共に使用されてよい。Ｍ２Ｍアプリケーション２０および２０’は、ＵＥまたはゲートウェイと相互作用するアプリケーションを含んでよく、かつ他の開示したシステムおよび方法と共に使用されてもよい。

一実施形態では、ＤＳＬＴ－ＴＦ１２０２、ＤＳＬＴ－ＭＦ１２０４および１２０６、ＤＳＬＴ－ＣＦ１２０８、１２１０、１２１２および１２１４、ＤＳＬＴ－ＭＦ ＡＰＩ１３０２、ＤＳＬＴ－ＭＦ処理１３０４、ＤＳＬＴ－ＭＦシーケンス処理１３０６、ＤＳＬＴ－ＭＦポリシーエンジン１３０８、ＤＳＬＴ－ＭＦスケジューラ１３１０、ＤＳＬＴ－ＣＦ ＡＰＩ１４０２、ＤＳＬＴ－ＣＦ処理１４０４、ＤＳＬＴ－ＣＦシーケンス処理１４０６、ＤＳＬＴ－ＭＦ ＣＳＦ２３０４、サービス層１０２、ＣＳＥ３０２、３０６および２３０２、ＮＳＥ３０８、ＩｏＴサーバ１１０２および１２３２、ＩｏＴゲートウェイ１２４２、ＩＮ－ＣＳＥ２７０２、ＡＳＮ－ＣＳＥ２７０４および２７０６などの論理的エンティティは、図３０Ｂに示すように、Ｍ２Ｍサーバ、Ｍ２ＭゲートウェイまたはＭ２ＭデバイスなどのＭ２ＭノードによってホストされるＭ２Ｍサービス層インスタンス内でホストされてよい。例えば、これらの論理的エンティティは、Ｍ２Ｍサービス層インスタンス内の個々のサービス性能を含むか、または既存のサービス性能内のサブ機能を同様に含んでよい。

Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、健康およびウェルネス、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視などの種々の業界でのアプリケーションを含むことができる。上記のように、システムのデバイス、ゲートウェイ、サーバおよび他のノードにわたって起動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、請求、位置追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合などの機能をサポートし、サービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。

概して、サービス層２２および２２’は、アプリケーションプログラミングインターフェース（ＡＰＩ）と下位ネットワークインターフェースとのセットを介して付加価値サービス能力をサポートするソフトウェアミドルウェア層を画定する。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍアーキテクチャの両方は、サービス層を規定している。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス性能層（ＳＣＬ）と称される。ＳＣＬは、ＥＴＳＩ Ｍ２Ｍアーキテクチャの種々の異なるノードで実装される可能性がある。例えば、サービス層のインスタンスは、Ｍ２Ｍデバイス（この場合、デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（この場合、ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（この場合、ネットワークＳＣＬ（ＮＳＣＬ）と称される）内に実装される可能性がある。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス性能）のセットをサポートする。１つまたは複数の特定のタイプのＣＳＦのセットのインスタンス化は、種々のタイプのネットワークノード（例えば、インフラストラクチャノード、ミドルノード、アプリケーション固有ノード）でホストされる可能性のある共通サービスエンティティ（ＣＳＥ）と称される。第３世代パートナーシッププロジェクト（Third Generation Partnership Project：３ＧＰＰ）は、マシンタイプコミュニケーション（Machine-Type Communications：ＭＴＣ）向けのアーキテクチャも規定している。そのアーキテクチャでは、サービス層およびサービス層が提供するサービス性能は、サービス性能サーバ（Service Capability Server：ＳＣＳ）の一部として実装される。ＥＳＴＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬまたはＮＳＣＬで、３ＧＰＰ ＭＴＣアーキテクチャのサービス能力サーバ（ＳＣＳ）で、ｏｎｅＭ２ＭアーキテクチャのＣＳＦまたはＣＳＥで、またはネットワークの他のいくつかのノードで具現化される、サービス層のインスタンスは、サーバ、コンピュータおよび他のコンピューティングデバイスまたはノードを含むネットワーク内の１つまたは複数のスタンドアロンノードか、または１つまたは複数の既存のノードの一部としてのどちらかで実行する論理的エンティティ（例えば、ソフトウェア、コンピュータ実行可能命令など）として実装することができる。一例として、サービス層のインスタンスまたはそのコンポーネントは、以下で説明され、図３０Ｃおよび３０Ｄに図示される基本的なアーキテクチャを有するネットワークノード（例えば、サーバ、コンピュータ、ゲートウェイ、デバイスなど）で動作するソフトウェアの形態で実装することができる。

さらに、本明細書で記載し、図に示した論理的エンティティは、本出願のサービスにアクセスするためにサービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用するＭ２Ｍネットワークの一部として実装することができる。

図３０Ｃは、Ｍ２Ｍデバイス１８、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍサーバ２２などのネットワーク装置３０の例示的ハードウェア／ソフトウェアアーキテクチャのブロック図である。装置３０のアーキテクチャを使用して、本明細書に記載され、かつ図に示された上述の論理的エンティティのいずれかを実装してよい。装置３０は、図３０Ａ～Ｂに示すようなＭ２Ｍネットワークの一部、または非Ｍ２Ｍネットワークの一部であってもよい。図３０Ｃに示すように、装置３０は、プロセッサ３２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド／インジケータ４２と、電源４８と、全地球測位システム（Global Positioning System：ＧＰＳ）チップセット５０と、他の周辺機器５２とを含んでもよい。装置３０は、送受信機３４および伝送／受信要素３６などの通信回路も含んでもよい。装置３０は、実施形態と一致したままで、上述の要素の任意の副次的組み合わせを含んでよいことを理解されたい。この装置は、本明細書に記載した機能を実装するノードであってもよい。

プロセッサ３２は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（Digital Signal Processor：ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連付けられた１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（Application Specific Integrated Circuit：ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（Field Programmable Gate Array：ＦＰＧＡ）回路、任意のその他のタイプの集積回路（Integrated Circuit：ＩＣ）、状態マシンなどであり得る。概して、プロセッサ３２は、装置のメモリ（例えば、メモリ４４および／またはメモリ４６）に記憶されたコンピュータ実行可能命令を実行して、装置の種々の必要とされる機能を実施してもよい。例えば、プロセッサ３２は、信号コーディング、データ処理、電力制御、入力／出力処理、および／または装置３０が無線または有線環境で動作することを可能にする任意の他の機能を実施してもよい。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（Radio Access-Layer：ＲＡＮ）プログラムならびに／もしくは他の通信プログラムを実施してもよい。プロセッサ３２は、例えば、アクセス層および／またはアプリケーション層などで、認証、セキュリティキー共有および／または暗号化操作などのセキュリティ操作も実施してよい。

図３０Ｃに示すように、プロセッサ３２は、その通信回路（例えば、送受信機３４および伝送／受信要素３６）と連結している。プロセッサ３２は、コンピュータ実行可能命令の実行により、通信回路を制御して、装置３０に接続されているネットワークを介して他のネットワーク装置と通信させてもよい。特に、プロセッサ３２は通信回路を制御して、本明細書および特許請求の範囲で記載される伝送および受信ステップを実施してもよい。図３０Ｃは、プロセッサ３２と送受信機３４とを別個のコンポーネントとして描写するが、プロセッサ３２と送受信機３４とは、電子パッケージまたはチップ内に一体化されてもよいことを理解されよう。

伝送／受信要素３６は、Ｍ２Ｍサーバ、ゲートウェイ、デバイスなどを含む他の装置に信号を伝送するまたはそこから信号を受信するように構成されてよい。例えば、一実施形態では、伝送／受信要素３６は、ＲＦ信号を伝送および／または受信するように構成されるアンテナであってもよい。伝送／受信要素３６は、ＷＬＡＮ、ＷＰＡＮ、セルラーなどの種々のネットワークおよびエアインターフェースをサポートしてよい。一実施形態では、伝送／受信要素３６は、例えば、ＩＲ、ＵＶ、もしくは可視光信号を伝送および／または受信するように構成されるエミッタ／検出器であってもよい。更に別の一実施形態では、伝送／受信要素３６は、ＲＦおよび光信号の両方を伝送ならびに受信するように構成されてよい。伝送／受信要素３６は、無線または有線信号の任意の組み合わせを伝送および／または受信するように構成されてもよいことを理解されよう。

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

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

プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６などの任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶してもよい。例えば、プロセッサ３２は、前述したように、そのメモリ内にセッションコンテキストを記憶してもよい。非取り外し可能メモリ４４は、ランダムアクセスメモリ（Random-Access Memory：ＲＡＭ）、読み取り専用メモリ（Read-Only Memory：ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含んでもよい。取り外し可能メモリ４６は、加入者識別モジュール（Subscriber Identity Module：ＳＩＭ）カード、メモリスティック、セキュアデジタル（Secure Digital：ＳＤ）メモリカードなどを含んでもよい。別の実施形態では、プロセッサ３２は、サーバまたは家庭用コンピュータなどの装置３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶してもよい。プロセッサ３２は、システムのステータスを反映するためにディスプレイ上の可視的表示を制御するか、あるいは、ユーザーからの入力を取得するか、もしくは性能または設定に関する情報をユーザーに表示するように構成されてもよい。ディスプレイに表示することができるグラフィカルユーザーインターフェースは、ユーザーが本明細書に記載される機能をインタラクティブに実行できるようにするＡＰＩの上に層化されてもよい。

プロセッサ３２は、電源４８から電力を得てよく、装置３０内のその他のコンポーネントへの電力を分配および／または制御するように構成されてよい。電源４８は、装置３０に給電するための任意の好適なデバイスであってよい。例えば、電源４８としては、１つまたは複数の乾電池（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ－ｉｏｎ）など）、太陽電池、燃料電池などが挙げられる。

プロセッサ３２はまた、装置３０の現在位置に関する位置情報（例えば、経度および緯度）を提供するように構成される、ＧＰＳチップセット５０に連結されてよい。装置３０は、実施形態と一致したままで任意の好適な位置決定方法を介して位置情報を取得してもよいことを理解されるであろう。

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

装置３０は、センサ、大衆消費電子製品、スマートウォッチまたはスマート衣類などのウェアラブルデバイス、医療またはｅ健康デバイス、ロボット、産業機器、ドローン、車、トラック、電車または飛行機などの乗物などの他の装置もしくはデバイス内で具現化されてもよい。装置３０は、周辺機器５２のうちの１つを備えることがある相互接続インターフェース等の１つまたは複数の相互接続インターフェースを介して、上記の装置もしくはデバイスの他のコンポーネント、モジュール、またはシステムに接続してもよい。あるいは、装置３０は、センサ、大衆消費電子製品、スマートウォッチまたはスマート衣類などのウェアラブルデバイス、医療またはｅ健康デバイス、ロボット、産業機器、ドローン、車、トラック、電車または飛行機などの乗物などの装置もしくはデバイスを含んでよい。

図３０Ｄは、Ｍ２Ｍサーバ、ゲートウェイ、デバイスあるいはその他のノードまたは装置などのＭ２Ｍネットワークの１つまたは複数の論理的エンティティまたはノードを実装するために使用することができる例示的コンピューティングシステム９０のブロック図である。コンピューティングシステム９０は、コンピュータまたはサーバを備えてもよく、ソフトウェアの形態（ソフトウェアが記憶されるまたはアクセスされる場所や手段は問わない）であってもよいコンピュータ可読命令によって主に制御されてよい。コンピューティングシステム９０は、ＤＳＬＴ－ＴＦ１２０２、ＤＳＬＴ－ＭＦ１２０４および１２０６、ＤＳＬＴ－ＣＦ１２０８、１２１０、１２１２および１２１４、ＤＳＬＴ－ＭＦ ＡＰＩ１３０２、ＤＳＬＴ－ＭＦ処理１３０４、ＤＳＬＴ－ＭＦシーケンス処理１３０６、ＤＳＬＴ－ＭＦポリシーエンジン１３０８、ＤＳＬＴ－ＭＦスケジューラ１３１０、ＤＳＬＴ－ＣＦ ＡＰＩ１４０２、ＤＳＬＴ－ＣＦ処理１４０４、ＤＳＬＴ－ＣＦシーケンス処理１４０６、ＤＳＬＴ－ＭＦ ＣＳＦ２３０４、サービス層１０２、アプリケーションプロトコル１０４、アプリケーション１０６、ＣＳＥ３０２、３０６および２３０２、ＡＥ３０４、７０４、７０６、７０８および２３０６、ＮＳＥ３０８、ＩｏＴアプリケーション１００２および１２３０、ＩｏＴデバイス１００４、１００６、１００８、１２３４、１２３６、１２３８および１２４０、ＩｏＴサーバ１１０２および１２３２、ＩｏＴゲートウェイ１２４２、ＩＮ－ＣＳＥ２７０２、ＡＳＮ－ＣＳＥ２７０４および２７０６、ならびに、インターフェース２９０２、２９０４、２９０６および２９０８などのインターフェースを作る論理的エンティティなどの論理的エンティティを実行または含んでよい。コンピューティングシステム９０は、例えば、Ｍ２Ｍデバイス、ユーザー端末、ゲートウェイ、ＵＥ／ＧＷ、または、モバイルコアネットワークのノード、サービス層ネットワークアプリケーションプロバイダのノード、端末デバイス１８またはＭ２Ｍゲートウェイデバイス１４を含む任意の他のノードであってよい。かかるコンピュータ可読命令は、コンピューティングシステム９０を稼働させるように、中央演算処理装置（Central Processing Unit：ＣＰＵ）９１などのプロセッサ内で実行されてよい。多くの既知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央演算処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央演算処理装置９１は、複数のプロセッサを備えることがある。コプロセッサ８１は、追加の機能を実施またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは異なる、任意選択のプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、セッション証明書を受信またはセッション証明書に基づく認証など、Ｅ２Ｅ Ｍ２Ｍサービス層セッションのために、開示されるシステムおよび方法に関連するデータを受信、生成、ならびに処理してよい。

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

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

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

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

さらに、コンピューティングシステム９０は、図３０Ａおよび図３０Ｂのネットワーク１２などの外部通信ネットワークに、コンピューティングシステム９０を接続するために使用され得るネットワークアダプタ９７などの通信回路を備えて、コンピューティングシステム９０がネットワークの他のノードと通信できるようにしてもよい。

ユーザー端末（User Equipment：ＵＥ）は、エンドユーザーが通信するために使用するいかなるデバイスであってよい。ユーザー端末（ＵＥ）は、ハンドヘルド電話機、モバイルブロードバンドアダプタを搭載したラップトップコンピュータまたは任意の他のデバイスであってもよい。例えば、ＵＥは、図３０Ａ～ＢのＭ２Ｍ端末デバイス１８または図３０Ｃのデバイス３０として実装されてよい。

本明細書に記載されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形態で具現化されてよく、その命令は、例えば、Ｍ２Ｍサーバ、ゲートウェイ、デバイスなどを含むＭ２Ｍネットワークのノードまたは装置などのマシンによって実行されると、本明細書に説明されるシステム、方法、およびプロセスを実施ならびに／もしくは実装することを理解されたい。具体的には、ＤＳＬＴ－ＴＦ１２０２、ＤＳＬＴ－ＭＦ１２０４および１２０６、ＤＳＬＴ－ＣＦ１２０８、１２１０、１２１２および１２１４、ＤＳＬＴ－ＭＦ ＡＰＩ１３０２、ＤＳＬＴ－ＭＦ処理１３０４、ＤＳＬＴ－ＭＦシーケンス処理１３０６、ＤＳＬＴ－ＭＦポリシーエンジン１３０８、ＤＳＬＴ－ＭＦスケジューラ１３１０、ＤＳＬＴ－ＣＦ ＡＰＩ１４０２、ＤＳＬＴ－ＣＦ処理１４０４、ＤＳＬＴ－ＣＦシーケンス処理１４０６、ＤＳＬＴ－ＭＦ ＣＳＦ２３０４、サービス層１０２、アプリケーションプロトコル１０４、アプリケーション１０６、ＣＳＥ３０２、３０６および２３０２、ＡＥ３０４、７０４、７０６、７０８および２３０６、ＮＳＥ３０８、ＩｏＴアプリケーション１００２および１２３０、ＩｏＴデバイス１００４、１００６、１００８、１２３４、１２３６、１２３８および１２４０、ＩｏＴサーバ１１０２および１２３２、ＩｏＴゲートウェイ１２４２、ＩＮ－ＣＳＥ２７０２、ＡＳＮ－ＣＳＥ２７０４および２７０６、ならびに、インターフェース２９０２、２９０４、２９０６および２９０８などのインターフェースを作るデバイスまたはエンティティの操作を含む、上述のステップ、操作または機能のいずれかが、コンピュータ可読記憶媒体に記憶されるコンピュータ実行可能命令の形態で実装されてよい。コンピュータ可読記憶媒体は、情報を記憶するための任意の非一時的（すなわち、有形または物理的）方法もしくは技術に実装される揮発性および不揮発性媒体、取り外し可能および非取り外し可能媒体の両方を含むが、そのようなコンピュータ可読記憶媒体は信号を含まない。コンピュータ可読記憶媒体としては、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ－ＲＯＭ、デジタル多用途ディスク（Digital Versatile Disks：ＤＶＤ）または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶デバイスまたは他の磁気記憶デバイス、もしくは所望の情報を記憶するために使用されてよく、かつコンピュータによってアクセス可能である任意の他の有形もしくは物理的媒体が挙げられるが、それらに限定されない。

さらに、図１１、１２、１５～２２、２７および２８に示したステップを実施するエンティティは、図３０Ｃおよび図３０Ｄに示したような無線および／またはネットワーク通信またはコンピュータシステム向けに構成される装置のメモリ内に記憶され、そのプロセッサで実行されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装されてもよい論理的エンティティであってよいことが理解される。すなわち、図１１、１２、１５～２２、２７および２８に示した方法は、図３０Ｃおよび図３０Ｄに示した装置またはコンピュータシステムなどの装置のメモリに記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装されてよいが、この際、該コンピュータ実行可能命令は、装置のプロセッサによって実行されると、図１１、１２、１５～２２、２７および２８に示したステップを実施するものである。図１１、１２、１５～２２、２７および２８に示した１つまたは複数のエンティティおよび関連する機能は、１つまたは複数の仮想化ネットワーク機能の形態で実装されてもよいことも理解される。ネットワーク機能は、必ずしも直接通信する必要はなく、むしろ、転送またはルーティング機能を介して通信してもよい。また、図１１、１２、１５～２２、２７および２８に示した任意の伝送および受信ステップは、装置の通信回路または装置のプロセッサの制御下にあるエンティティ、およびそれが実行するコンピュータ実行可能命令（すなわち、ソフトウェア）によって実施されてよいことも理解される。

「リクエストの送信」、「応答の送信」、「リクエストの受信」、「応答の受信」などの表現は、通信ネットワークを介して、通信ネットワークのエンティティへ／エンティティからのメッセージを（例えば、パケットの形態でまたは他の定義されたビットのシーケンスで）送信または受信することを含む場合がある。ここで、メッセージの内容またはデータは、リクエストまたは応答されている内容を受信先に通知するものであることもさらに理解される。したがって、例えば、「リクエストの送信」という表現は、「メッセージリクエストの送信」、「リクエストを含むメッセージの送信」などの表現と、同等のものである場合がある。

図に示す本開示の主題の好ましい実施形態を説明する際に、明確にするために、特定の用語を使用する。ただし、特許請求の範囲に記載する主題は、そこで選択した特定の用語に限定されることを意図するものではなく、各特定の要素は、同様の目的を達成するために同様の方式で動作する全ての技術的等価物を含むことを理解されたい。

本明細書の実施例は、最良の態様を含む本発明を開示し、任意のデバイスまたはシステムの作製かつ使用および任意の組み込まれた方法の実行を含む本発明の実施を可能にするために使用される。本発明の特許性のある範囲は、特許請求の範囲によって定義され、当業者に想起される他の実施例を含み得る。そのような他の実施例は、特許請求の範囲の文言通りの構造要素を有する場合に、または特許請求の範囲の文言と大きく異ならない同等の構造要素を含む場合に、特許請求の範囲の範囲内であることを意図している。

Claims (20)

1. プロセッサおよびメモリを備える装置であって、
   前記装置は、
   前記装置の前記プロセッサによって実行されると、
   前記装置に通信ネットワークの第１サービス層エンティティを実行させ、
   前記第１サービス層エンティティに、
   前記通信ネットワーク上で実行されるアプリケーションから、分散トランザクションのリクエストであって、前記通信ネットワークの複数の他のサービス層エンティティによってホストされているターゲットリソースのセットで原子的に実行されるコマンドを規定するリクエストを受信し、
   前記複数の他のサービス層エンティティのそれぞれに、該他のサービス層エンティティによってホストされているターゲットリソースのいずれかをロックするようにリクエストを送信し、
   前記複数の他のサービス層エンティティのそれぞれから、該サービス層エンティティが該サービス層エンティティによってホストされている前記ターゲットリソースをロックできたかどうかを示す応答を受信し、
   前記複数の他のサービス層エンティティが前記ターゲットリソースのセットをロックできたことを示す応答の受信に基づいて、前記複数の他のサービス層エンティティに前記ターゲットリソースのセットで前記コマンドの原子的実行を実施するようにリクエストを送信し、
   前記複数の他のサービス層エンティティから、前記コマンドが前記ターゲットリソースのセットで正常に実行されたことを示す応答を受信し、
   前記コマンドが前記ターゲットリソースのセットで正常に実行されたことを示す応答の受信に基づいて、前記複数の他のサービス層エンティティに前記分散トランザクションをコミットするようにリクエストを送信し、
   前記アプリケーションに前記分散トランザクションが正常に実施されたことを示す応答を送信する、
   各手順を実行させる、前記装置の前記メモリに記憶されたコンピュータ実行可能命令をさらに備える装置。
2. 前記コンピュータ実行可能命令はさらに、前記アプリケーションから前記分散トランザクションの前記リクエストを受信すると、前記第１サービス層エンティティの前記メモリ内に、前記分散トランザクションを表し、かつ前記分散トランザクションの状態に関する情報を含むリソースを前記第１サービス層エンティティに生成させ、
   前記リソースは、前記アプリケーションが前記通信ネットワークを介してアクセス可能なものである、請求項１に記載の装置。
3. 前記リソースは、前記トランザクションを一意に識別するトランザクション識別子属性と、前記分散トランザクションの前記状態に関する前記情報が保存されているトランザクション状態属性とを含む、請求項２に記載の装置。
4. 前記リソースは、前記第１サービス層エンティティが前記分散トランザクションの前記リクエストの処理をいつ開始するかを制御する実行時間属性を含む、請求項２に記載の装置。
5. 前記装置は、前記通信ネットワークのサーバまたはゲートウェイのうち１つを含む、請求項１に記載の装置。
6. 前記コンピュータ実行可能命令はさらに、前記第１サービス層エンティティに、前記リクエストの処理に関するルールを定義するポリシーに従って前記分散トランザクションの前記リクエストを処理させる、請求項１に記載の装置。
7. 前記コンピュータ実行可能命令はさらに、前記第１サービス層エンティティに、前記分散トランザクションの処理をスケジュールさせる、請求項１に記載の装置。
8. 前記分散トランザクションの前記リクエストは、リクエストのシーケンスの一部である、請求項１に記載の装置。
9. 前記コンピュータ実行可能命令はさらに、前記第１サービス層エンティティに、前記コマンドの前記実行に対する制約を示す基準を前記複数の他のサービス層エンティティへ送信させる、請求項１に記載の装置。
10. 前記コンピュータ実行可能命令はさらに、前記第１サービス層エンティティに、リクエストされた前記分散トランザクションの優先順位の割り当てをさせる、請求項１に記載の装置。
11. 通信ネットワークの第１サービス層エンティティが、前記通信ネットワークで実行されるアプリケーションから、分散トランザクションのリクエストであって、前記通信ネットワークの複数の他のサービス層エンティティによってホストされているターゲットリソースのセットで原子的に実行されるコマンドを規定するリクエストを受信することと、
    前記複数の他のサービス層エンティティのそれぞれに、該他のサービス層エンティティによってホストされているターゲットリソースのいずれかをロックするようにリクエストを前記第１サービス層エンティティが送信することと、
    前記複数のサービス層エンティティのそれぞれから、該サービス層エンティティが該サービス層エンティティによってホストされている前記ターゲットリソースをロックできたかどうかを示す応答を前記第１サービス層エンティティが受信することと、
    前記複数の他のサービス層エンティティが前記ターゲットのセットをロックできたことを示す応答の受信に基づいて、前記複数の他のサービス層エンティティに前記ターゲットリソースのセットで前記コマンドの原子的実行を実施するようにリクエストを前記第１サービス層エンティティが送信することと、
    前記複数の他のサービス層エンティティから、前記コマンドが前記ターゲットリソースのセットで正常に実行されたことを示す応答を前記第１サービス層エンティティが受信することと、
    前記コマンドが前記ターゲットリソースのセットで正常に実行されたことを示す応答の受信に基づいて、前記複数の他のサービス層エンティティに前記分散トランザクションをコミットするようにリクエストを前記第１サービス層エンティティが送信することと、
    前記アプリケーションに前記分散トランザクションが正常に実施されたことを示す応答を送信することと
    を含む方法。
12. 前記アプリケーションから前記分散トランザクションの前記リクエストを受信すると、前記分散トランザクションを表し、かつ前記分散トランザクションの状態に関する情報を含むリソースを前記第１サービス層エンティティが生成することをさらに含み、前記リソースは、前記アプリケーションが前記通信ネットワークを介してアクセス可能なものである、請求項１１に記載の方法。
13. 前記リソースは、前記トランザクションを一意に識別するトランザクション識別子属性と、前記分散トランザクションの前記状態に関する前記情報が保存されているトランザクション状態属性とを含む、請求項１２に記載の方法。
14. 前記リソースは、前記第１サービス層エンティティが前記分散トランザクションの前記リクエストの処理をいつ開始するかを制御する実行時間属性を含む、請求項１２に記載の方法。
15. 前記第１サービス層エンティティは、前記通信ネットワークのサーバまたはゲートウェイのうち１つに実装される、請求項１１に記載の方法。
16. 前記リクエストの処理に関するルールを定義するポリシーに従って、前記分散トランザクションの前記リクエストを処理することをさらに含む、請求項１１に記載の方法。
17. 前記分散トランザクションの処理のスケジューリングをさらに含む、請求項１１に記載の方法。
18. 前記分散トランザクションの前記リクエストは、リクエストのシーケンスの一部である、請求項１１に記載の方法。
19. 前記複数の他のサービス層エンティティに、前記コマンドの前記実行に対する制約を示す基準を送信することをさらに含む、請求項１１に記載の方法。
20. リクエストされた前記分散トランザクションに優先順位を割り当てることをさらに含む、請求項１１に記載の方法。

Images