CData Software Blog

クラウド連携のCData Software の技術ブログです。

100+の外部API 連携をサポートするアーキテクチャの解説~CTO によるドライバー技術解説 第二弾~

本記事は、CData Software CTO のTomas Restrepo 氏の英語の記事の日本語訳です。

私の前回のBlog 記事 では、ドライバー開発を含むデータ連携の際にどのような要素を考慮するかを説明しました。今回の記事では、CData Drivers のアーキテクチャを説明します。読者の皆様には、CData がどうやって100を超えるデータソース×多くのテクノロジー向けに、高品質なドライバーを安定提供できているかをイメージしてもらえればと思います。また、本記事は複数の外部API に連携する製品を開発する開発者の方々の技術的な指針となるはずです。

ハイレベルな概要:

f:id:cdatasoftware:20181210230214p:plain
CData Drivers のアーキテクチャ

最上層:フロントエンドテクノロジー

この図の上にはODBCJDBCADO.NET などのCData がサポートするテクノロジーが並んでいます。これをここではドライバーのフロントエンドと呼ぶことにします。これらのフロントエンドがそれぞれのテクノロジーインターフェースにCData ドライバーをサポートさせています。(訳者注:本記事では「テクノロジー」「エディション」と呼ばれるものは、ODBCJDBCSSIS、PowerBI などの種類を指します。)

中間層:コアコードベース

真ん中には、ドライバーのコアとなるコードベースがあります。この層は2つのカテゴリに大別されます。1つ目は多くのドライバーに共通する機能を実装するDriver Services です。この記事でいくつかの機能についてはより深く説明します。

ドライバーコアの2つ目は、Data Access Stack (アクセス層)です。アクセス層はCData のアーキテクチャの大事な部分です。これにより、クエリ実行時にドライバーコアの上下にレイヤーを拡張することができます。

最下層:データソース特化コード

そして一番下の層はデータソースに特化したコードで、真ん中の層の拡張ポイントとデータソース特化コードとのクエリ実行のためのアクセス実装を含みます。ここにはデータソースに特化したデータアクセス層も含まれます。(訳者注:本記事では「データソース」「プロバイダー」はSalesforce、Dynamics CRM、kintone、BigQuery などを指します。)

フロントエンドのテクノロジー

図の最上部はドライバーのフロントエンドです。100を超えるデータソースをODBCJDBCADO.NETExcel Add-in、SSIS、BizTalk、PowerBI、RADStudio などCData がサポートするプラットフォームに応じたインターフェース技術でアクセス可能にします。それぞれのフロントエンドテクノロジーは2つの部分で実装されています:

  • すべてのドライバーに共通のコア実装 - すべてのドライバーに共通する機能で内部フレームワークとして実装されています。そこにドライバー固有のコードがプラグインされる形です。例えば、JDBC の実装には、StatemetResultSet などのコアJDBC コンセプトの実装があります。

  • ドライバー固有のインターフェース実装 - この部分はすべて自動コード生成により実装され、フレキシブルな作りになっています。

この自動コード生成は、CData 技術のカギとなるもので、これにより新しいデータソースへの迅速な対応や新しい連携テクノロジーへの対応が実現できています。

自動コード生成の概要:

それぞれのドライバーで、核となるとなるメタデータを宣言型言語で定義します。これには以下のような基本的な情報が含まれます:

  • ドライバー名、概要など

  • サポートされる接続プロパティ、および関連ドキュメント

  • ドライバーがサポートするテクノロジーエディション

次に定義されたメタデータからビルドタイムにより以下を自動生成します:

この自動化レイヤーにより、CData のドライバー開発プロセスは最大限効率的かつフレキシブルになっています。JDBCODBC といった異なるインターフェースのドライバーの製品ビルドから製品のヘルプドキュメントまで宣言型言語で定義された同一のメタデータから自動的にビルドされているのです。考えてみましょう。

それぞれのドライバーにおいて、どのテクノロジーをサポートするかを選択できます。もし、あるデータソースにBizTalk アダプターを提供する必要がないと判断されれば、他のドライバーだけをビルドすることができます。より現実的なシナリオとしては、ドライバーのベータ版リリースを早くするために、JDBCODBC などのいくつかの主要なドライバーテクノロジーに絞ったリリースをするケースがあげられます。

CData では、共通のコンフィギュレーションオプションや接続プロパティを一度だけ開発し、他のドライバーでも再利用することができます。この共通化によりすべてのドライバーにおいて統一された共通の動作を期待できます。例えば、ほぼすべてのドライバーにはファイアウォールおよびプロキシサーバーの設定プロパティがあり、接続プロパティの共通仕様として実装されています。こういった実装をCData では1か所だけで行い、すべてのドライバーで統一仕様として使われるようにしています。

新しい接続文字列やオプションを開発する際も一度開発すれば、他のエディションでも利用が可能になります。もちろん、特定のエディションのみで適用されるオプションを作成することやコンフィギュレーションをシンプルにするために隠しプロパティとすることが可能です。新しいドライバーを開発する際には、テクノロジー固有のフレームワークおよびプロバイダー固有コードは、定義された共通インターフェースを通じてドライバーにつながれます。もしドライバーのテクノロジー固有実装部分にバグがあったり、新しい機能を追加する際には、自動コード生成テンプレートを調整することで、他のドライバーにも同じものを適用することができます。

このモデルにより、CData は新しいテクノロジープラットフォームへの対応や、複数のプラットフォーム向けの新ドライバーを素早く開発してリリース、メンテナンスをすることができます。固有実装部分は一度だけテンプレートとして書き、それを他のポートフォリオでも利用可能とするのです。

まとめ

この記事では、CData Drivers のハイレベルなアーキテクチャを説明しました。

CData の開発フレームワークはフロントエンドのコード自動生成に根差しており、複数のテクノロジーに向けたネイティブドライバーをサポートできるアーキテクチャとなっています。これにより、CData のドライバーは複数のプラットフォーム上でも、素早いアップデートや機能追加に対し統一的な実装を保てるのです。

次の記事ではコアドライバーサービスについて説明します。