Delegation

リッチなツールを実現することに加えて、IRPでファーストクラスのメタデータとディスカバリーをサポートする目的の一つは、IRPに準拠したシステム間の相互運用性と委譲を可能にすることでした。

In addition to enabling rich tooling, one of the goals of having first-class metadata and discovery support in IRP was to enable interoperability and delegation across IRP-compliant systems.

IRPシステムが他のIRPシステムで定義されたアーティファクトを発見する機能を提供することで、豊富なクエリプランニングと配信機能を構築することができます。これには、リンクまたは登録された様々なIRPサービスのカタログを集約する単純な「メタIRP」サービス（SQL Serverの「リンクサーバ」に類似）から、IRPサービスに配置するために式を分割して書き換えることによる分散型ストリーミングイベント処理までが含まれます。

By providing the ability for an IRP system to discover the artifacts defined in another IRP system, rich query planning and distribution capabilities can be built. This can range from simple “meta-IRP” services that aggregate the catalog of various linked or registered IRP services (similar to “linked servers” in SQL Server), all the way to distributed streaming event processing by splitting and rewriting expressions for placement on IRP services.

例として、次のようなイベント処理のクエリ式を考えてみましょう。

As an example, consider the following event processing query expression:

code:C#

var bartHome = ctx.Bart.GeoLocation.Select(g => home - g.Location < 100 * METER).DistinctUntilChanged();

var lisaHome = ctx.Lisa.GeoLocation.Select(g => home - g.Location < 100 * METER).DistinctUntilChanged();

var bothHome = bartHome.CombineLatest(lisaHome, (b, l) => b && l).First(both => both);

バートとリサの地理座標のストリームを使用して、彼らの現在の場所と家の間の距離を計算し、投影を使用して家に到着したかどうかを判断します（参照：Select）。また、DistinctUntilChangedを使って隣接する重複をフィルタリングし、家に入る（false→true）と家を出る（true→false）に対応する「エッジ」イベントを取得します。

Using the stream of geo-coordinates of Bart and Lisa, we calculate the distance between their current location and home, to determine whether they have arrived at home using a projection (cf. Select). We also filter out adjacent duplicates using DistinctUntilChanged, which gets us the “edge” events that correspond to entering home (false to true) and leaving home (true to false).

次に、この2つのクエリをCombineLatestを使って結合し、両方が在宅しているかどうかを表すイベントを生成し、Firstを使って両方が在宅していることを示す最初のイベントを選択します。

Next, we combine these two queries using CombineLatest to generate events that represent whether both are home, selecting the first event that indicates both are home using First.

1つの可能な実装では、BartとLisaの両方のジオロケーションのストリームを単一のIRPサービスで定義し、そこですべての処理を集中的に行うことができます。しかし、自宅までの距離の計算や重複するイベントのフィルタリングは、GPSセンサーから直接供給されるBartとLisaのデバイスで行う方が効率的です。これにより、デバイスとクラウドサービスという複数のノードにまたがるイベントの転送が削減されます。IRPのメタデータ・ドリブン・デレゲーションのコンセプトは、このシナリオを可能にします。

In one possible implementation, we have the streams of geo-locations for both Bart and Lisa defined in a single IRP service, where we can perform all the processing centrally. However, it’d be more efficient for the distance to home calculations and the filtering of duplicate events to happen on Bart’s and Lisa’s devices, feeding off the GPS sensor directly. This reduces the transport of events across nodes, in this case devices and a cloud service. The concept of metadata-driven delegation in IRP enables this scenario.

上記の例では、ctxインスタンスは、IRPに準拠したサービスのクラウドのルートとして機能し、BartとLisaのためのIRPインスタンスなどの特定のサービスへの移行を可能にします。このような階層的アプローチは、世界を表現する1つの方法に過ぎません。別の方法としては、フラットな世界を表現し、ターゲットとなるIRPサービスのバインダーに、論理的な識別子に対してDNSのような方法でアーティファクトの位置を発見させることもできます。トラバーサルパターン（ctx.Bart.GeoLocationなど）を用いた階層的アプローチは、（Bartなどの）エンティティが生データだけでなく、静止しているデータ（IEnumerable<T>）や動いているデータ（IObservable<T>）へのトラバーサルを公開できる、反応型グラフデータベースのアイデアに沿ったIRPの思考の別の場所を明らかにしています。

In the example shown above, the ctx instance acts as the root for a cloud of IRP-compliant services, allowing traversal into specific services such as the IRP instance for Bart and Lisa. This hierarchical approach is just one way of representing the world; an alternative would be to present a flat world and have the binder of the target IRP service discover the location of artifacts in a DNS-like fashion for logical identifiers. The hierarchical approach with traversal patterns (such as ctx.Bart.GeoLocation) reveals another place in the IRP thinking where we aligned with the reactive graph database idea where entities (such as Bart) can expose raw data as well as traversals into data at rest (IEnumerable<T>) or data in motion (IObservable<T>).

この世界観では、ARPサービス自体がARPのファーストクラスのアーティファクト・タイプであり、他のアーティファクト（ストリーム、サブスクリプションなど）と同様に識別子を使用して表現されます。コンテキスト・オブジェクトは、リソース階層をエンコードするトラバーサル・パターンを表す式で表されます。上記の例では、BartとLisaの両方が、利用可能なリアクティブ・アーティファクトを公開する（仮想）IRPサービスへのプロキシとなっています。

In this world view, IRP services themselves are first-class artifact types in IRP; they are represented using an identifier just like any other artifact (such as streams, subscriptions, etc.). A context object is represented by an expression representing a traversal pattern that encodes a resource hierarchy. In the example shown above, both Bart and Lisa are proxies to (virtual) IRP services exposing the reactive artifacts made available for them.

上記のような式のバインディングは、リンクされたカタログを使用したアーティファクトの検索を活用し、識別子の階層のトラバーサルを可能にします。上記の例では、ctxで示されるターゲットサービスは、Bartで示されるIRPインスタンス（KnownResource属性で設定された識別子を持つ）を検索する機能を持ちます。続いて、そのターゲットIRPインスタンスのメタデータサービスを参照することで、GeoLocationアーティファクトを検索することができます（同様にアーティファクト識別子を使用）。

Binding of expressions like the one shown above leverages lookups of artifacts using linked catalogs, allowing for the traversal of hierarchies of identifiers. In the example shown above, the target service represented by ctx has capabilities to look up the IRP instance denoted by Bart (which has an identifier set through a KnownResource attribute). By subsequently consulting the metadata service of that target IRP instance, the GeoLocation artifact can be looked up (similarly using an artifact identifier).

次に、これらのソースに適用される演算子（上記の例ではWhere、DistinctUntilChanged、CombineLatestを使用している）は、データを中央の場所にストリーミングすることによってctxで表されるIRPサービスに適用することができます。しかし、IRPのメタデータAPIを使用して、Bart.GeoLocationおよびLisa.GeoLocationに関連付けられたIRPインスタンス内のそのような演算子の利用可能性を発見することもできます。同様に、そのような演算子に渡される述語やセレクタなどで参照される関数も発見でき、初歩的な能力ベースのクエリプランニングや分散実行計画の作成を効果的に行うことができます。

Next, the operators applied to these sources (cf. the use of Where, DistinctUntilChanged, and CombineLatest in the example above) could be applied in the IRP service represented by ctx by streaming the data to a central location. However, IRP’s metadata API can also be used to discover the availability of such operators in the IRP instances associated with Bart.GeoLocation and Lisa.GeoLocation. Similarly, functions referenced by predicates, selectors, etc. passed to such operators can also be discovered, effectively enabling rudimentary capability-based query planning and the creation of distributed execution plans.

IRPの真の分散実装には、単なる能力ベースの式のタイリングを超えて、分散実行プランの経済性を決定するための追加の帯域外のメカニズムが含まれています。これは、メタデータエンティティ上で公開されている追加プロパティの利用可能性に関する規約（ストリームのボリュームと速度の推定値、データ転送のコスト、セキュリティ要件など）や、（コストベースの）クエリプランニングを支援するために使用できる追加サービスの利用可能性に基づいています。

A true distributed implementation of IRP contains additional out-of-band mechanisms to decide on the economics of a distributed execution plan, beyond mere capability-based tiling of expressions. These can be based on conventions about availability of additional properties exposed on the metadata entities (e.g. volume and velocity estimations for streams, cost of transporting data, security requirements, etc.) or the availability of additional services that can be used to aid in (cost-based) query planning.

このクエリプランニングの例は、Cortanaのシナリオを導入する際に考えられたもので、「（約束の）出発時間」などのクエリには、ユーザーのデバイスの地理座標データや交通状況に関するイベントを使用する必要があります。デバイス上（GPSセンサーデータなど）とクラウド上（公共交通データなど）のストリーム処理機能を、同じ統一されたIRP抽象化を用いてモデル化することで、クエリ式を異なるIRP実装上で実行可能なサブ式に分割することができました。

This example of query planning was first conceived when onboarding Cortana scenarios where queries such as “time to leave” (for an appointment) require the use of geo-coordinate data on users’ devices as well as events related to traffic conditions. By modeling stream processing capabilities on the device (cf. GPS sensor data) and in the cloud (cf. public traffic data) using the same unifying IRP abstraction, we were able to split a query expression into subexpressions that can run on different IRP implementations.

現在のReaqtorの実装では、分散型委任の組み込みサポートは限られていますが（ただし、Reaqtorフレームワーク上に構築されたサービス実装では、そのような機能が構築されています）、Partitioned Multi Subject (PMS)と呼ばれるメカニズムを介して、クエリ演算子をストリームプロキシにインメモリで委任するために同じ手法を使用していました。PMSと互換性のあるストリームにWhereフィルタを適用する際には、決定/ルーティングツリーとして効率的に評価するために、フィルタ条件をストリームのインメモリプロキシ実装に委譲しようとする委譲ダイアログが設定されます。

Today’s implementation of Reaqtor has limited built-in support for distributed delegation (though service implementations built on top of the Reaqtor framework have built such capabilities) but used the same technique for in-memory delegation of query operators into stream proxies through a mechanism called Partitioned Multi Subject (PMS). When applying a Where filter to a stream that’s PMS-compatible, a delegation dialogue is set up to attempt to delegate the filter conditions to the stream’s in-memory proxy implementation for efficient evaluation as a decision/routing tree.

たとえば、weather.Where(w => w.City == "Seattle")のようなクエリを素朴に実行すると、各イベントの述語が評価されることになります。このようなサブスクリプションが多数存在する場合、各イベントのすべての述語を線形に評価することになります。PMSで採用されているローカルデリゲーションは、辞書ベースの評価ツリーが構築されるウェザーストリームへの述語のプッシュダウンを可能にします。受信したすべてのイベントについて、Cityプロパティが抽出され、下流のオブザーバーを検索するために、その値に一致する辞書エントリ（例：Seattle）と照合されます。これにより、評価コストはサブリニアになります。

For example, naive executon of a query like weather.Where(w => w.City == "Seattle") would result in evaluation of the predicate for each event. When many such subscription exist, this results in a linear evaluation of all predicates for each event. The local delegation employed by PMS enables pushdown of the predicate to the weather stream where a dictionary-based evaluation tree is built. For every event received, the City property is extracted and checked against a dictionary entry matching the value (e.g. Seattle) in order to retrieve downstream observers. This leads to sub-linear evaluation cost.