もしあなたが最近のCorda 5のブログポストをお読みであれば、Cordaのアーキテクチャが変化していることは既にご存知でしょう。この変更に伴い、Corda サービスと総称される機能についても再考が必要です。

Flowは Corda アプリケーションの主要な構成要素で、定義されたライフサイクルでビジネスプロセスをカプセル化するには最適ですが、アプリケーションはしばしばFlowとしてモデル化するのが複雑な機能を実装する必要があります。そこで、Cordaサービスを利用することができます。上記のように、Corda サービスはノード自身と同じライフサイクルを共有するクラスの長期間のインスタンスです。ノードがCordaサービスを作成するとき、AppServiceHub のインスタンスをServiceクラスに渡します。これによりサービスは Corda API にアクセスできるようになり、アプリ開発者は以下のようなユースケースを実現するための、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プラットフォームの一部として実現される様子を示しています。分散アーキテクチャが可能にする高可用性と水平スケーリングの利点を活用できていることがわかると思います。

トークンセレクションとソフトロックは、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は外部システムにコストのかかる呼び出しをすることなく、信用格付けにアクセスできるようになります。

Corda 5では台帳Hookという新しいフレームワークが提供されます。アプリ開発者が台帳の変更に対応して呼び出されるフックを開発できるようになりました。これらはCorda 4の古いVault observablesによって提供された機能を置き換えるものです。 プラットフォームは開発者が使用できるように、様々なクラスのフックを提供します。

Cordaが実用できるためには、他システムと接続できることが重要です。Corda 5の新しいHTTP APIは外部からCordaと対話するための豊富なAPIを提供します。一方、CorDappが内部から外部（他システム）へと対話する必要があるケースも多く存在します。

そのために設計されたのが、新しいExternal Connectivity APIです。このAPIはFlowと台帳HookがKafkaトピック（またはトピックのペア）またはHTTPエンドポイントの2つのチャンネルで外部システムに接続することを可能にします。Kafkaについては、開発者が独自のKafkaトピックを定義し、新しいAPIを介してアドレス指定することができまる。HTTPの場合、開発者は新しいAPIを使用して、外部接続サービスを提供しているワーカーへアクセス可能な任意のURLにアクセスできます。

Corda 5 で導入されたエキサイティングな新しいアーキテクチャはパフォーマンス、スケーラビリティ、信頼性とデプロイの柔軟性のための新しい機会を提供し、Cordaを利用する参加者たちがより効率的にリソースを使用することを可能にします。

この投稿で、古いカスタム Corda Services を削除しても、Corda 4 でできたことすべてとそれ以上のことができる、エキサイティングな新しいアプリを構築するための柔軟性をアプリ開発者に提供する予定の概要をご理解いただけたと思います。近い将来、これらの新しいサービスの詳細とその使用方法について説明する一連のブログ記事を公開する予定です。