LSID（Life Sciences Identifier：生命科学データ名）は新しい名前のデータ・アクセス・プロトコルで、IBM他オラクル、サン・マイクロシステムズ、マサチューセッツ工科大学など技術組織の協力によりI3C.org (Interoperable Informatics Infrastructure Consortium)で開発されているものです。クライアント・アプリケーションはデータとデータに関する情報（メタデータ）検出のために、「オーソリティ 」と呼ばれる特別なサーバーでLSIDを解決します。

当然ながらLSID解決の理想は、バイオテクノロジー（生物工学）、薬学他すべての生命科学に関わる組織が、それぞれの持つデータに関してLSID 解決サービスを構築することにあります。データ検索に関しての共通標準を持つことで、こうした組織にまたがる科学者達が新薬発見や病理研究といった生命に関わるプロジェクトで協力し合ったり、データ交換したりすることが容易になります。LSID サーバー・フレームワークは、組織がそれぞれの持つデータ・ソースに最適なサービス方法でデータを提供できるようにすることで、LSIDの理想世界を現実のものとしようとしています。あるデータ・ソースではLSIDからURLへのマッピングが必要なだけかもしれません。個々のデータがURLを持っていて、標準フォーマットでそのデータを持ってこられるようになっているなら、マッピングですむからです。データ・ソースがリレーショナル・データベースなら、もっと複雑なサービスが必要になります。

この記事ではJava 2 エンタープライズ・エディッション (J2EE)ベースのコンポーネントを使って解決サービスを構築する方法を説明します。ここではLSID クライアント・スタック（アプリケーション内でのLSID接続性を提供）、LSID サーバー・フレームワーク（これによりLSID 解決サービスの開発・展開が迅速にできます）、また解決サービス実装のうち重要なものなどについて見ていきます。最後に、各組織は企業LSID 解決ネットワークを構築するために、こうしたコンポーネントをどのように統合すべきかを見ることにします。この記事に出てくる図は各コンポーネントのアーキテクチャを説明していますが、同時にコンポーネント間での連携動作も説明しています。赤で示した文字や矢印は鍵となるJavaのクラスがどう関連するか表しています。

LSIDクライアント・スタック

LSID クライアント・スタックは簡単ですが非常に重要なLSID 解決ネットワークのコンポーネントです。これにより、ネットワーク上の生命科学アプリケーションはLSIDで提供されるデータを容易に利用できるようになります。LSID クライアント・スタックにはJavaだけでなく、C++/COMやPerl実装もあり、実質的にどんなアプリケーションとでも統合できるようになっています。3つのAPIは各言語固有のプログラミング技法や設計パターンに基づいており、同等の機能が確保されています。図1は、あるアプリケーションに埋め込まれたLSID クライアント・スタックを示しています。

このスタックはurn:lsid:authority:namespace:objectの形でLSIDを与えられると、最初はローカルにリストされているオーソリティ・エンドポイントURLに対し、次に必要あればDNSに対し、「オーソリティ」の実際のホストを解決します。要求があるとこのスタックは、解決されたオーソリティに対するgetAvailableOperations Webサービス・コールを通じて、データとメタデータの位置を含むWSDLドキュメントを訂正します。そして次にWDSLにあるメタデータとデータ位置を構文解析し、その位置をHTTP、FTP、またはSOAPでの検索に使います。これらの位置は同じサーバー（オーソリティ）にある必要はなく、普通の場合、同じサーバー上には無いでしょう。ユーザーは特定の位置、特定のプロトコルを指定することもできるし、スタックにすべての選択を任せることもできます。こうした柔軟性のおかげでWDSLはユーザーの必要に応じてきめ細かい制御ができるようになっていますが、ユーザーにはそれを意識させません。

クライアント・スタックにはファイルベースのキャッシング・モジュールがあり、繰り返しのデータ、メタデータやWSDLリクエストに対する応答時間を劇的に改善しています。ユーザーがリクエストを出すと、クライアント・スタックはそのレスポンスを返すのにネットワーク経由で探しに行く前に、まずファイル・キャッシュをチェックします。ネットワーク・リクエストが完了すると、スタックはネットワークのレスポンスをキャッシュに書き込みます。キャッシュ上のアイテムのライフサイクルはローカル・ポリシーとレスポンスの有効期限に依存します。ローカル・ポリシーは、一つのアイテムがどのくらいの期間生き得るかと、キャッシュ・ディレクトリの最大サイズを規定します。さらに、メタデータのサービスやオーソリティがクライアントに対して、メタデータやWSDLの有効期限を示すヘッダーを返す場合もあります。LSIDの仕様によれば、データそれ自体は不変なので、キャッシュされたデータの期限が切れることはありませんが、ローカルのキャッシュに関する方針に従って削除されることはあり得ます。

上に戻る

LSID サーバー・フレームワーク

LSID 解決サービスをまったく初めから構築するのは困難ですし、非常に時間もかかります。それに、リクエストを構文解析し、そのレスポンスを監視するのはどんな実装でも共通なものです。LSID サーバー・フレームワークはLSIDサービスの開発を容易にするためにサーバーでの共通プロトコル処理を提供しており、またLSIDプロトコルをサービス実装から分離しています。

このシステムにはオーソリティ・サービス、データ・サービス、メタデータ・サービスの 3つのコンポーネントがあります。各コンポーネントは、実用的なメソッドを含むJavaインターフェースを定義しています。オーソリティ・サービス の場合であればgetKnownURIsとgetAvailableOperationsです。getKnownURIsはオーソリティが知っているリスト、つまりLSIDを返します。getAvailableOperationsはLSIDのデータやメタデータを検索して取り出せる位置を記述したWDSLドキュメントを返します。3番目のオーソリティ操作、getAuthorityVersionはこのインターフェースに含まれていないことに注意して欲しいのですが、これはオーソリティ・バージョンというのはプロトコルのバージョンを指すからです。プロトコルのバージョンはHTTP/SOAPヘッダーやSOAPの戻り型のような詳細な部分に隠れているため、サービス実装が抽出します。データ・サービスとメタデータ・サービスのインターフェースはそれぞれデータ（getData）、メタデータ（getMetaData）を検索するメソッドを含んでいます。

各サービスは対応するHTTPサーブレットAuthorityServlet、DataServlet、MetaDataServletが処理します。各サーブレットはメソッド、引数それにリクエストがターゲットとするLSID（SOAPのパラメータやURLの一部かもしれません）を構文解析します。サーブレットはターゲットLSIDを使ってサービス・レジストリの中を見、コンフィグレーションされたサービス実装のうちどれを起動するかを決めます。参照手順はLSIDのオーソリティと名前空間のコンポーネントをレジストリのマッピングと比較します。例えば、urn:lsid:pdb.org:pdb:1aftはPDBAuthorityImplが操作し、urn:swiss-prot.org:swiss-id:hv20_mouse-sprotはSWISSAuthorityImplが操作します。

AuthorityServletはHTTP SOAPによってのみ、その動作をエクスポーズします。AuthorityServletサーブレットはgetAuthorityVersionに対して、使っているプロトコルのバージョンを瞬時に返します。現在のリリースではプロトコルのバージョンは3です。getKnownURIsに対しては、マッピングが登録されている各オーソリティ実装のgetKnownURIsを起動し、判明している全LSIDの完全なリストを提供します。getAvailableOperationsに対しては、LSID引数を使い、データとメタデータ位置のWSDL検索の対象となるオーソリティ実装を参照します。

DataServletは唯一の操作であるgetData操作を、HTTPのGetとHTTP SOAPでエクスポーズします。SOAPに対しては、LSIDは単一のSOAPパラメータに含まれます。HTTPGetに対しては、LSIDはクエリー・ストリングの中、例えばhttp://www.myappserver.com/lsid/data?lsid=urn:lsid:foo:barにあることになっています。MetadataServletも同じように動作しますが、メタデータ・サービス実装がメタデータ検索のヒントに使用できるような、追加の引数を持っています。SOAPに対しては、この引数はURLに埋め込まれています。例えばhttp://www.myappserver.com/lsid/metadata/metadata-hintのように。HTTP Getに対してはLSIDとそのヒントに2つのリクエスト・パラメータを使います。例えば、http://www.myappserver.com/lsid/metadata?lsid=urn:lsid:foo:bar&hint=metadata-hintです。

ある一つのLSID 解決サービスはオーソリティ・サービスから成ってさえいれば良いことになっています。データ・サービスとメタデータ・サービスはある意味、データとメタデータのエンドポイントを提供するユーティリティでしかありません。例えばあるデータ・プロバイダーはデータに対してちょうど良いHTTPの位置、getAvailableOperationsWSDLで直接参照できるような位置を既に持っているかもしれません。

セキュリティ

LSID 解決ネットワークでのセキュリティはプロトコルレベルで処理されます。HTTPサービスではHTTP基本認証が使用されます。SOAPサービスでは、その下層にあるトランスポート・プロトコルに対する認証が使われます（現在の実装ではHTTP）。LSID クライアント・スタックとLSID サーバー・フレームワークはこうした2つのケースを処理します。

上に戻る

LSID解決サービス実装

下記に示すLSID 解決サービスのいくつかの例では、LSID サーバー・フレームワークがどのように使われるかを説明します。

キャッシング・プロクシ解決サービス

キャッシング・プロクシ解決サービス（HTTPプロクシのLSID版）は、ネットワーク（研究所内、部署内、組織内等のネットワーク）の末端に位置して全LSIDトラフィックを代行するものです。さらにこのプロクシは、同じLSIDで動作しているシステムを使っている研究者に応答時間が早く感じられるように、LSIDのリクエストをキャッシュします。キャッシング・プロクシ解決サービスはまた、組織内でのLSIDトラフィックのモニター手段にもなります。図2はキャッシング・プロクシ解決サービスを示します。

キャッシング・プロクシ解決サービスはクライアント・スタックを使って他のサービスに対するリクエストを代行します。クライアントにキャッシュ機能があるおかげで、プロクシはキャッシュされたリクエストに素早く応答できます。キャッシング・プロクシはDNSで解決可能なLSIDはどれでも処理できるので、このプロクシの持つ既知のURIのリストは本来、LSIDのグローバル空間であると言えます。ところが良く考えてみれば、getKnownURIsが起動したときにWSDLキャッシュしたLSIDを戻すだけなのです。

キャッシング・プロクシ解決サービスはオーソリティ・サービス、データ・サービス、メタデータ・サービスから成っています。getAvailableOperationsに対し、プロクシはクライアント・スタックを使ってgetAvailableOperations自体をコールし、プロクシが受け取るレスポンスに基づいて別のWSDLを構築します。このWSDLにはプロクシにある、データ、メタデータ・サービス位置があります。プロクシがgetDataに対するリクエストを受け取ると、データ自体はどの位置でも同一なので、元のWSDLにある任意のデータ位置に対してリクエストを出します。ところが、各メタデータ位置には異なったメタデータがあり得るので、それぞれの元の位置はプロクシからエクスポーズする必要があります。メタデータのポート名は、WSDLで戻すURLのヒントにエンコードします。ですからgetMetaDataに対するリクエストを受け取ったときには、それをある特定のメタデータ位置へとリレーすることができるのです。

ゲートウェイ解決サービス

ゲートウェイ解決サービスはXMLベースの言語を提供します。この言語はASDL (Authority Service Description Language：オーソリティサービス・システム記述言語）と呼ばれ、オーソリティ・サービスの動作を明示的に記述するものです。ASDLドキュメントにはLSIDと、それに対応するデータやメタデータ位置のリストが含まれています。現在、このドキュメントはリレーショナル・データベースまたはフラット・ファイルストアから自動生成される必要があります。Javaの通常の表現でマッピングが規定でき、オーソリティの全体が手書きのXML数行で記述できるようなバージョンは現在開発中となっています。

ゲートウェイには2つの使い方があります。1つ目の例は図3にありますが、ローカルのデータ・ストアに対してLSIDベースのビューを提供することです。開発者はローカルのデータ・ストアをスクレープするデータ(任意の部分を切り出すデータ）、メタデータのサービス実装を提供する必要があります。こうした実装には、例えばリレーショナル・データベースのテーブルを読むのにJDBCを利用したりすることもできます。ASDLファイルのエントリーはDataServletとMetaDataServletの位置を参照します。

２つ目の例は図4に示しますが、多分もっと強力なものです。生命科学のデータ・プロバイダーが静的または動的URLでデータをエクスポーズすると（実際多くのプロバイダーがそうしています）、サードパーティーの開発者が、そうしたデータに対する仮想LSIDを割り当てるASDLドキュメントを構築できます（もちろん、許可を得た上でですが）。ASDL中のデータ、メタデータ位置はその前からあったURLを指します。

現実的には、サードパーティーのデータを提供するのに、２つを組み合わせたやり方が使えます。ASDLファイルは元データ・ソースを指すURLと、データ・サービスとメタデータ・サービスの一方または両方を指すURL、の両方を含みます。一般的にこうしたサービスはリクエストを元データ・ソースURLにリレーします。このアーキテクチャでは、データがSOAPとHTTP両方で提供されることが保証されることになります。これは、データ・プロバイダーがFTPアクセスのみしか許可しないときには必要になります。全クライアントがFTPをサポートしていることはあり得ません。ただ、リクエストのリレーは単に2つのプロトコルの橋渡し以上のことをする必要があります。例えば、サードパーティーのデータソースの、元のURLはフォーマットされたHTMLページを参照しているかもしれません。リレー・サービスはこうしたページの実際のデータも、標準フォーマットで提供するためにスクレープする必要があるかもしれません。

カスタム解決サービス

ASDLがデータ、メタデータのマッピングを記述するのに不十分な場合には、図５に示すようなカスタム実装も可能です。

オーソリティ・サービスを構築する上で最も複雑で厄介なのは、getAvailableOperationsに応ずるWSDLを構築することです。サーバー・フレームワークは抽象クラスSimpleAuthorityとSimpleResolutionServiceで簡単なインターフェースを提供します。開発者は、SimpleAuthorityを使って、ある指定されたLSIDに対するメタデータとデータの位置を返すメソッドを実装しさえすればよいのです。この情報はWSDLを構築するのに使われます。図5ではSimpleAuthorityを継承するためにLSIDAuthorityImplを記述します。SimpleResolutionServiceは、メタデータ・サービスとデータ・サービスが共にオーソリティ・サービスでホストされるような共通ユース・ケースをさらに抽象化します。LSIDMetaDataServiceImplとLSIDDataServiceImplは、SimpleResolutionServiceを継承する一つのクラスに統合できます。この派生クラスはまた、データとメタデータ・リクエストを自身に向かわせる、一つのオーソリティサービス実装です。

蛋白質データベース

カスタム解決サービスの一例はPDB（Protein Data Bank：たんぱく質データバンク）オーソリティです。PDB オーソリティはHTTP、FTP取り混ぜてのデータ位置と、これらの位置からのデータを代理するSOAPエンドポイントを返します。PDB オーソリティはまた、LSIDを相互に関連付け、また外部資源へのリンクを提供する、包括的RDFを生成するメタデータサービスを提供します。

図6はPDB オーソリティのアーキテクチャです。簡便のため、一貫した解決サービスは単にオーソリティとしています。このオーソリティが返すWSDLにはPDB データ・サービスからのFTP、HTTPダイレクトデータロケーションとSOAPデータロケーションの両方があります。

ハイブリッド（混成）オーソリティ

多くのオーソリティ実装は単一のサーブレットがホストしているので、ハイブリッドオーソリティのホストというのもあり得ます。例えば、あるLSIDセットの直接オーソリティでもあるキャッシング・プロクシ解決サービスを考えてみてください。ある生物学研究所のクライアント・アプリケーションという観点で見てみれば、そのサービスがLSIDを解決するのに研究所外まで出る必要があるかどうかによらず、データの検索プロセスは一定で切れ目無く見えるでしょう。そうしたサービスは、例えば製薬会社のように研究者が内部データソースと外部のデータソースを統合する必要がある企業・組織にとって中心オーソリティとなります。このサービスが扱う外部のLSIDが増えてくると、キャッシュは大きくなり、その結果、外部データへのアクセスがより高速にできるようになります。

図7はハイブリッド解決サービスを示しています。曲がった矢印は、サーブレットが異なるサービス実装に対してリクエストをディスパッチ（送出）する様子を表します。myauthをオーソリティとするすべてのLSIDは、ローカル LSID サービスで処理され、他のすべてのLSIDはキャッシング・プロクシで処理されます。

上に戻る

企業LSID解決ネットワーク

この記事の最初でお話したLSIDの理想世界を実現するにはそれぞれの組織が、組織内サービスが外部にも使えるという前提の下、ハイブリッドキャッシング解決サービスに基づいた企業解決ネットワークを構築していく必要があります。どちらもそうしたネットワークを持った、2つの研究所を考えてみてください。どちらの研究所のクライアント・アプリケーションも、統合されたデータをまったく同じように見ることができるのです。こうした対象性だけでなく、そのクライアント・アプリケーションはLSIDベースの外部のデータソース（例えばPDBやゲートウェイ・ベースのデータソース）にアクセスできるようにもなるのです。独立した外部のユーザーが、あるクライアント・アプリケーションを使うことで、そうした解決ネットワークにアクセスすることもできるようになるのです。こうした関係を図8に示します。

上に戻る

今後

理想世界の夢は別として、より多くのプロバイダーがデータを提供するのにLSIDを使うようになればLSID 解決サービスもより有効なものとなるでしょう。よく知られているような生命科学データソース、例えばPDB、Genbank、Pubmed、Swissprot、GeneOntology、LocuslinkそれにEnsemblなどにはLSID 解決サービスがあります。ちょっとした作業をするか外部委託で作るかすれば、どんな組織でも既存のデータベースをLSIDで提供できるようになります。

残る問題としては、科学者や研究者が個人的なデータや結果、論文、レポートその他の書類に、どうやってLSIDを動的に割り付けるかという点です。この問題が大前提として解決できないと、LSID 解決ネットワークが目標とするデータ統合や協力体制を完全に実現することはできません。マサチューセッツ州ケンブリッジのLSID開発チームはこの新しい問題を解決すべく、現在努力を重ねています。

参考文献

• サーバー、クライアント、それにサンプルの解決サービスコードをdeveloperWorks の LSID project summary pageからダウンロードしてください。
  
  
• LSIDプロジェクトについてさらに詳しく知りたい場合はLSID Web siteを見てください。
  
  
• Linux上にLSID認定システムを構築するではLSID Resolution Serviceを構築するための詳細を説明しています。
  
  
• 資源記述フレームワークのメタデータ・フォーマットについてはRDFを見てください。
  
  
• 蛋白質データバンクについてはpdb.orgを見てください。
  
  
• Genbank、Pubmed、それにLocuslinkについてはNational Center for Biotechnology Informationのホームページを見てください。
  
  
• EnsemblについてはEnsembl project pageを見てください。
  
  
• Swiss-Protについては、ExPASy Molecular Biology ServerのSwiss-Prot pageを見てください。
  
  
• 遺伝子存在論についてはGene Ontology Consortiumのホームページを見てください。
  
  
• developerWorks ではオープン・ソース・ソフトウェアの生物化学や研究機関一般での使用に関して、2つの記事を発表しています。生物科学におけるオープン・ソースは主に情報科学の面から説明し、研究室におけるオープン・ソースはデータ解析に関してPerl、Python、オープン・ソース・ツールキットなどを説明しています。
  
  
• developerWorks のopen source projects 、 Java technology、 Web servicesなどにある資料も参考にしてください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• LSIDクライアント・スタック
• LSID サーバー・フレームワーク
• LSID解決サービス実装
• 企業LSID解決ネットワーク
• 今後
• 参考文献
• 著者について
• コメント