SAP SQL Anywhere 16 における OData のサポート

[Sawa_Ito]

このページは、以下の英語ページの抄訳です。最新の情報については、英語ページを参照してください。

 

紹介

 

OData は、web でのデータ交換の技術の「Lingua Franca」として急速に広がってきました。OData 標準では、クエリを発行し、リレーショナルデータベース、ファイルシステム、コンテンツ管理システム、そして典型的な Web サイトなどを含む（しかしそれに限定されない）リモートデータソースを更新するための言語構造とプロトコルを定義しています。これは、HTTP や RESTful web サービス、Atom Publishing Protocol (AtomPub)、XML、Javascript Object Notation (JSON) などといった既存のWebテクノロジー上に構築されています。

 

SAP は SQL Anywhere version 16 を2013年3月にリリースしましたが、これには多くのクールな新機能が数多く含まれています。このブログは、その中の一つの機能、SQL AnywhereへのODataのアクセスのサポートについて解説します。   

 

備考:  SQL Anywhere 16.0 は、version 12.0.1 に続くバージョンです。バージョン 13、14、15はありません。 

 

バックグラウンド

 

SQL Anywhere は、実は SOAP と REST-ベースのWebサービスをすでにversion 9.0 でサポートしていました！Webアクセスを有効にするには、サーバーを内部のHTTP リスナーをスタートする新しいコマンドラインスイッチとともに起動する必要がありましたが、これにより、データベースサーバー自身がwebサーバーとして起動し、入ってくるHTTPs / リクエストをハンドリングすることができました。データベース内部では、開発者は、定期的なSQL クエリをテーブル、ビュー、またはストアドプロシージャーに投げる別のSERVICEオブジェクトを作成し、結果セットをXML、HTML、JSONなどの複数のフォーマットに変換します。以下の図1は、基本的なアーキテクチャーを示します。TCP/IPポートを介してサーバーとODBC/JDBC クライアント/サーバー接続され、また別のポートからHTTP/S 接続され、HTTP リスナーで処理されました。

 



 

 

これは、とても良い機能だったのですが、以下のマイナス面もありました。

1. HTTP web サーバーコンポーネントは、ODBC/JDBC接続とは別のポートから接続されていましたが、ファイアウォールにポートを開け、実際のデータベースサーバーの処理がオープンなインターネットに公開されることを意味していました。通常、ネットワーク管理者にとって、特にデータベースサーバーのような重要なリソース標準外のポートをファイアウォールに開けるのは問題がありました...


2. この SERVICE オブジェクトは、公開されてしまうテーブル、ビュー、プロシージャーとは別のデータベースオブジェクトでした。これらは特定のSQL Anywhere シンタックスで書き、別に維持しておく必要がありました。スキーマ変更は、WSDL for any SOAP servicesなどのサービスオブジェクトには自動的に反映しませんでした。


3. これらのサービスにアクセスする URI は、物理的なデータベース名を含ませる必要がありました。例えば：

http://<servername>:<port>/<database name>/<service name>

これはデータベースサーバーに対する悪意のある攻撃に使用される可能性のある情報です。

 

 

SQL Anywhere 16.0 のアーキテクチャー

 

SQL Anywhere 16 では、OData のサポートのために新しいサーバープロセスを導入しました。名前は、 DBOSRV16.EXE　で、2つの全く別のコンポーネントから構成されています。

 

1. DBOSRV16.EXE HTTP サーバー。これは、Jetty オープンソース Java サーブレットコンテナです。この処理は、SQL Anywhere 16 データベースの外部で実行され、web クライアントからのHTTP または HTTPS 接続を受信します。


2. OData プロデューサー Java サーブレット。これは、SQL Anywhere データベースへのJDBC 接続を開き、ODataクエリの処理と更新を実行し、 AtomPub (XML) フォーマットの結果セットでも JSONフォーマットの結果セットでも返信します。OData プロデューサーサーブレット コードが提供され、Java サーブレットを実行できるどのWebサーバー内でもコンパイルして実行することができます。

 

この新しいセットアップの機能の中で最も良いのは、データベースオブジェクト（テーブルとビュー）が自動的にODataプロデューサーに公開されるという点です。別々のSERVICE オブジェクトを作成して維持する必要はもうありません。さらに、HTTP リクエストは、データベースサーバーを直接ヒットしないので、重要なリソースのセキュリティレベルを上げられます。

 

ところで、これは、既存のWeb サービスインフラストラクチャー - つまり、SQL Anywhere 16 に存在する全てのもの - をリプレースするものではない、ということを認識することが重要です。これらの機能は、既存のアーキテクチャーへ追加されるものです。下の図2 では、web リクエストを管理するDBOSRV16.EXE プロセスで変更されたアーキテクチャーを示します。

 



 

はじめに

 

一番最初のステップは、もちろんSQL Anywhere 16 のライセンスを入手してインストールすることです。  (SAP でも、SQL Anywhere の開発者向け無償ライセンスは継続して提供されます)

すでに、重要なサービスパックが出ています。Build #1535 以上を入手してください。SQL Anywhere 16 (そしてそれ以前のバージョン) のオンラインマニュアルは、 DocCommentExchange サイト.に掲載されています。

 

SQL Anywhere 16 のサンプルフォルダーは、 \Users\Public\Documents\SQL Anywhere 16 フォルダーにインストールされます。ODataサンプルは、 \SQLAnywhere\ODataSalesOrders とand \SQLAnywhere\ODataSecurity のフォルダーにあります。

 

\ODataSalesOrders フォルダの中にあるserver.bat ファイルを開きます。このファイルのキーとなるラインは、DBOSRV16.EXEをスタートする以下のラインです。:

start "dbosrv16" "%__SABIN%\dbosrv16" SalesOrdersConfig.properties

 

これは、 「SalesOrdersConfig.properties」ファイルに格納されている設定オプションを使用して新しい DBOSRV16.EXE 処理をロードします。このために、そのファイルにある関連オプションは、HTTP リスナーポートで、認証スタイルです。この例では、ポート8090を使用し、一般的なユーザー/パスワードを使用してSQL Anywhere 16 サンプルデータベースに接続します。SSL 認証、ロギングファイルロケーション、verbosity、データベース認証オプション、などいくつかのその他の設定オプションがあります。

 

start_server.bat ファイルを実行して、DBOSRV16 OData サーバーを起動します。

 

 

OData クエリの実行

 

私の好みは Google Chromeですが、Firefox でもOData 接続のテストにはうまく機能します。「service root」と呼ばれている以下のURLを入れてください。

http://localhost:8090/odata

 

結果は、Service Document と呼ばれているもので、これは、エンティティコレクションサービスからキューイングされるセットを表します。注意して欲しいのは、これはSQL Anywhere 16 サンプルデータベースで、プライマリキーがあるもの全てです。プライマリーキーを持たないビューとテーブルをどのように含めるのかは、次のセクションで説明します。

 

ディレクティブを付加して Metadata Document を入手し、XML スキーマとしてサービスにより公開された全てのデータを定義します。

 

http://localhost:8090/odata/$metadata

 

個別のエンティティを問い合わせるには、エンティティ名をサービスのルートに付加します。Products テーブルを問い合わせ、XML 構造体を返す方法は以下のとおりです。

 

http://localhost:8090/odata/Products

 

JSON 形式で応答を見たい場合には、$format ディレクティブを追加します (注意：Products エンティティ名の後に続く「?」は、エンティティURI とクエリオプション間のセパレーターとして使用します）:

 

http://localhost:8090/odata/Products?$format=json

 

OData には、SQL 分同様に機能する一連のクエリオプションのセットが含まれています。

• $format- 返されたデータの構造体としてjson、xml、またはatom を選択します。


• $select - エンティティ (テーブルなど) から特定の属性 (カラムなど) を選択


• $orderby - 特定の属性でソート


• $filter - SQL のWHERE 句と同様に機能


• $top - 返された結果セットを最初のN 行に限定


• $skip - スキップ値がNにセットされている場合、返される最初の行は N+1 になる


• $expand - 特定の外部キーがある場合、ネストされたサブクエリ結果をリンクエンティティーに含めることが可能

 

 

OData プロデューサーサービス言語 (.OSDL) ファイル

 

デフォルトでは、OData プロデューサー servlet は接続されたユーザーが権限をSELECT した全テーブルとビューを公開します。またテーブルは、定義されたプライマリキーを有している必要があります。なぜならば、ビューはプライマリキーを持っていないので、OData サービスドキュメントに自動的には含まれないからです。ビューまたはテーブルをプライマリキーなしで公開するには、.OSDL ファイルを作成し、サーバーの起動.propertiesファイルで特定する必要があります。

 

\samples\SQLAnywhere\ODataSecurity フォルダには、 .OSDL ファイルのサンプルが含まれています。基本的には、これは、エンティティのプライマリキーとして使用するコラム名が記載されたテーブルとビューの名前のリストです。.OSDLファイルを使用する場合には、サービスドキュメントに公開される全テーブルまたはビューを特定する必要があります。つまり、サンプルの secureView.osdl ファイルは、そのEmployeeConfidential ビューに対して単一のエンティティしか含まないため、これがOData プロデューサーによって公開される唯一のエンティティになります。

 

 

まとめ

 

SQL Anywhere 16 における新しい OData サーバーのプロセスには、多くの利点のポテンシャルがあります。

 

1. バックエンドやEIS のヘビーな開発を必要とせずODataサービスをすぐに作成・モデリングできるので、開発スピードとプロトタイプのフェーズの期間を短縮することができます。


2. HTTPが直接データベースサーバーにアクセスする必要がなくなり、本番のwebサービス環境のセキュリティを強化することができます。


3. JSON またはXMLにデータを変換するだけの中間層のコンポーネントを書く必要がなくなり、層構成のアプリケーション全体の複雑性を低減することができます。

 

 

 

 

 
===

 

SAP SQL Anywhere に関する詳細情報は、SAP SQL Anywhere Communityページ<英語> を参照してください。

 

上記のコミュニティーに掲載されている技術情報は、順次SQL Anywhere　日本語コミュニティ

に掲載しています。

 

SQL Anywhere に関してはまずはこちらをご参照ください。無期限でご利用いただける無償の Developers Edition もこちらからダウンロードが可能です。

 

SQL Anywhere に関して技術的な質問のある方はコミュニティに登録し、
「Ask a Question」機能をご利用ください。

Language には「Japanese」、
Primary Tag には「SAP SQL Anywhere」を選択
User Tagに「sql anywhere」「sql anywhere Japanese question」

を入力してください。

不具合につきましては、サポート契約者様専用の問い合わせ方法にてお問い合わせください。

 

======================
ご購入に関するお問い合わせ

こちらよりお問い合わせください。