Corda 5の新しいアーキテクチャとサービスの変更点、及びアプリ開発者への影響
Cordaサービス
もしあなたが最近のCorda 5のブログポストをお読みであれば、Cordaのアーキテクチャが変化していることは既にご存知でしょう。この変更に伴い、Corda サービスと総称される機能についても再考が必要です。
そもそもCordaサービスとは？
Flowは Corda アプリケーションの主要な構成要素で、定義されたライフサイクルでビジネスプロセスをカプセル化するには最適ですが、アプリケーションはしばしばFlowとしてモデル化するのが複雑な機能を実装する必要があります。そこで、Cordaサービスを利用することができます。上記のように、Corda サービスはノード自身と同じライフサイクルを共有するクラスの長期間のインスタンスです。ノードがCordaサービスを作成するとき、AppServiceHub のインスタンスをServiceクラスに渡します。これによりサービスは Corda API にアクセスできるようになり、アプリ開発者は以下のようなユースケースを実現するための、Cordaサービスを書くことができるようになります。
- 共通コード ： Corda サービスの最も基本的な機能として、開発者が異なるタイプのFlowで共有できる共通コードをカプセル化できるようにすることです。
- 共有データ ： Corda サービスはノードのライフタイムを通じて存在します。その為、複数のフローまたは同じフローの複数の呼び出しの間で共有されるデータを保存するために使用することができます。
- 台帳(Vault)の監視： Corda サービスはノードの起動時に台帳（Vault）の更新を監視することができます。これにより、開発者は外部システムへのフィードを構築したり、Flowのトリガーロジックを作成したり、将来のオペレーションをスケジューリングすることができます。
- バックグラウンド タスク処理 ： Web サービスへのコールアウトなど、バックグラウンド タスクを実行する必要があるFlowは、External Operations API を使用して Corda サービスに作業を委譲することができます。これにより、バックグラウンドのオペレーションが完了する間、他のFlowを実行することができます。
Corda5において、Corda サービスはどうなるのか？
簡単に言うことはできないのですが、、、Corda 5にはCorda サービスはありません!厳密な意味で無くなるということではありません。ただ、Corda 4.xのサービスとは全く違うものになりますし、同じものを用意しない理由も興味深いものです。
冒頭で述べたように、Corda 5から、Cordaの基本アーキテクチャが大きく変更されます。この変更は高可用性と水平スケーリングをサポートしますが、Corda サービスで提供される機能の実現方法にも影響を与えます。私たちにとって最も重要な変更は、仮想ノードの導入です。
Corda 5において、仮想NodeはCorDappの論理的な実行コンテキスト（Identity、ストレージ、ネットワークアドレス指定など）をカプセル化しますが、物理的な実行コンテキストはカプセル化されません。
これは論理ノードと物理ノード（JVMプロセス）が一体であったCordaの以前のバージョンからの大きな飛躍です。
Nodeのアーキテクチャをこのように変更することで、プラットフォームはクラスタ内のすべての利用可能なリソース（＝ワーカー）にFlowの実行をスケジューリングすることができるようになります。この分散実行により、Corda 5はCorda 4では利用できなかった高可用性と水平スケーリングを実現することができます（Corda 5の仮想ノードに関する詳細についてはこちらのブログ記事（仮想ノードによるリソース最適化：日本語化未着手）を参照してください）
このアーキテクチャから分かることは、Corda5において、同じ仮想Nodeに対する2つのFlowが同じプロセスで実行される保証はないということです。実際、1つのFlowがサスペンド/レジュームサイクルの間にプロセス（ワーカー）を切り替える可能性すら、非常に高いものになります。上の図にあるように、Nodeとプロセスの親和性を壊すことは、NodeがすべてのFlowからアクセス可能な長時間稼働のサービスをホストする機能を失うことを意味します。そして、以前のバージョンのCordaで使われていた、Cordaサービスの長時間稼働するという前提が意味をなさなくなることになります。
Corda 5を使用するアプリ開発者にとっては、新しいAPIセットと特別なプラットフォームサービスが、これまでCorda サービスで構築されていた機能を実装するために利用できるようになります。上の図は、サービスやAPIがCorda 5プラットフォームの一部として実現される様子を示しています。分散アーキテクチャが可能にする高可用性と水平スケーリングの利点を活用できていることがわかると思います。
Corda 5の新サービスAPI
トークンセレクション
トークンセレクションとソフトロックは、Stateを選択して消費したいCorDappのための重要な機能です。Flowが使いたいStateを「ロック」できるようにすることで、同時に走る他のFlowが同じStateを選択するのを防ぐことができます。これにより、Notaryによる署名を行う際にTransactionが失敗する原因となる二重消費のリスクを最小限に抑えることができます。Corda 4.xでは、トークンセレクションはCorda サービスの上に構築されているToken SDKによって提供されていました。Corda 5では、トークンセレクションがプラットフォームの一部として提供されます。用意される新しいAPIによってFlowがひと固まりのStateを照会し、消費できるようになります。アプリ開発者は、トークンセレクションと新しい台帳Hook（下記参照）を組み合わせて、Stateの選択やStateをロック可能かどうかなどの条件の制御などを実現できるようになります。
キーバリューストアの提供
既存のCordaサービスのよくある使われ方は、Flow間でStateを共有することです。Corda 5では、プラットフォームは各仮想ノードに対してシンプルで高速なキーバリューストアを提供する予定です。Flowは新しい一群のAPIを使って、アプリケーションデータをデータストアに（並行稼働チェックをしつつ）読み書きすることができます。
例えば、CorDappは外部システムから取引先の信用格付けを取得する必要があるかもしれません。そして、この作業はFlow上で行うにはコストのかかりすぎる操作かもしれません。この場合、キーバリューストアは信用格付けをキャッシュするために使われ、それによって後続のFlowは外部システムにコストのかかる呼び出しをすることなく、信用格付けにアクセスできるようになります。
台帳Hooks
Corda 5では台帳Hookという新しいフレームワークが提供されます。アプリ開発者が台帳の変更に対応して呼び出されるフックを開発できるようになりました。これらはCorda 4の古いVault observablesによって提供された機能を置き換えるものです。 プラットフォームは開発者が使用できるように、様々なクラスのフックを提供します。
- トークンセレクションHook — このフックは元帳のTransactionを受け取り、トークンセレクションサービスで使われる選択可能なトークンを出力します。例えば、CorDappはトークンセレクションを通じて、通貨選択できるようにしたいかもしれません。この場合、フックはどの状態が選択可能かをフィルターするために使われるかもしれない。
- 外部イベントHook — このフックを使うと、台帳の活動に対応して、外部システム（下記の外部接続性の項を参照）にメッセージを発行することができます。例えば、あるCorDappは特定の基準に合致する取引について、規制システムに通知する必要があるかもしれません。この場合、フックを使用してトランザクションが基準に当たるかどうかを識別し、規制システムに送信することができたりします。
- スケジュールFlowの開始Hook — このフックは、開発者が台帳上のイベントに対応してFlowを開始することを可能にします。このフックでは、オプションとして、開発者がイベントを起こすべき（将来時点の）データや時間を指定することができます。これは、個々のStateに対して用意される将来発行予定のFlowのスケジューリングを容易にします。例えば、CorDappは、一定の間隔で債券のクーポンを支払う必要があるかもしれません。この場合、フックを使って、特定のクーポンの日に支払いFlowを実行するようにスケジューリングすることができます。
外部接続API
Cordaが実用できるためには、他システムと接続できることが重要です。Corda 5の新しいHTTP APIは外部からCordaと対話するための豊富なAPIを提供します。一方、CorDappが内部から外部（他システム）へと対話する必要があるケースも多く存在します。
そのために設計されたのが、新しいExternal Connectivity APIです。このAPIはFlowと台帳HookがKafkaトピック（またはトピックのペア）またはHTTPエンドポイントの2つのチャンネルで外部システムに接続することを可能にします。Kafkaについては、開発者が独自のKafkaトピックを定義し、新しいAPIを介してアドレス指定することができまる。HTTPの場合、開発者は新しいAPIを使用して、外部接続サービスを提供しているワーカーへアクセス可能な任意のURLにアクセスできます。
- Kafka publish — Flowまたは台帳hookがユーザー定義のKafkaトピックにメッセージを発行できるようにします。例えば、CorDappは、完了したTransactionのサマリーデータをレポートシステムに発行したいと思うかもしれません。この場合、台帳hookやFlowは、レポートシステムが使用できるよう、サマリーデータを公開（publish）することができる。
- Kafka リクエスト/レスポンス — Flowがユーザー定義のKafkaトピックにリクエストメッセージを公開（publish)し、ユーザー定義のレスポンストピックでレスポンスを待つことができるようにします。例えば、CorDappは、支払いを行う前に、外部システムからの承認を必要とする場合があります。この場合、Flowは外部システムに承認リクエストを発行し、支払いを続行する前に応答を待つことができます。
- HTTP リクエスト/レスポンス — Flowが単純なRESTエンドポイントを呼び出し、レスポンスを待つことを可能にする。例えば、CordAppは、インターネット上で公開されているデータを使用して、検証プロセスの一部としてLegal Entity Identifier（LEI）をチェックしたいと思うかもしれない。この場合、Flowは LEI の詳細を取得するために URL に対して HTTP GET を実行する API を使用することができる。
まとめ
Corda 5 で導入されたエキサイティングな新しいアーキテクチャはパフォーマンス、スケーラビリティ、信頼性とデプロイの柔軟性のための新しい機会を提供し、Cordaを利用する参加者たちがより効率的にリソースを使用することを可能にします。
この投稿で、古いカスタム Corda Services を削除しても、Corda 4 でできたことすべてとそれ以上のことができる、エキサイティングな新しいアプリを構築するための柔軟性をアプリ開発者に提供する予定の概要をご理解いただけたと思います。近い将来、これらの新しいサービスの詳細とその使用方法について説明する一連のブログ記事を公開する予定です。
＜ご質問・ご要望の例＞
- Corda Portalの記事について質問したい
- ブロックチェーンを活用した新規事業を相談したい
- 企業でのブロックチェーン活用方法を教えて欲しい 等々
SBI R3 Japan エンジニアリング部長
書籍出してます：https://amzn.asia/d/c0V31Vd
趣味：サッカー、ガンプラ、ドライブ、キャンプ