第1章 レジストリとは？

1.1. はじめに

JBoss Enterprise SOA Platform のレジストリ実装に関する概要については、本章を参照してください。
レジストリは、アプリケーションやビジネスにの集約ポイントを提供して、ここにサービスの情報を格納できます。レジストリは、従来の「マーケットプレース」と同じレベルの情報、同じ幅のサービスを提供するよう期待されています。理想としては、レジストリは、動的な環境を提供することで e-commerce トランザクションの自動検出、実行がスムーズに行われるようにするはずです。そのため、レジストリは単なる e-business のディレクトリではなく、サービス指向アーキテクチャーの基本的なコンポーネントとなっています。

1.2. レジストリが必要な理由

手動、または特別な手法を使用して、簡単にビジネスパートナーを検出、管理して、規模が小さな状態でビジネスパートナーとつながります。しかし、この手法は、サービス数やインタラクションの頻度が増え、環境が分散していくと、うまく対応できません。レジストリがあれば、一般的かつユビキタスな方法でサービスを検出・公開し同意した基準に従いソリューションを提供することができます。
パートナーのサービスが社内の技術と互換性があるかどうかをクエリすることができるように集約管理します。
レジストリはサービス指向アーキテクチャーの集約部となる理由を説明していきます。実行時、サービスリクエストが実際の動作と相関可能なコンタクト地点として、レジストリは機能します。
レジストリは、実行時、設計時の両方で利用されるサービス指向アーキテクチャーのアーチファクトすべてに対して、メタデータエントリを保持します。
これらのアーチファクトには、様々なサービスやセキュリティデータ (証明書や監査追跡ログなど) を表すサービスやアイテムで使用するサービスポリシーの説明、Extensible Mark-Up Language (XML) スキーマといったアイテムが含まれます。
設計フェーズで、業務プロセスのアーキテクトは、様々なサービスへの呼び出しを連携するレジストリを使用する場合があります。こうすることで、ワークフローまたは業務プロセスを作成します。
ビジネスアナリストの観点からすると、レジストリはインターネット検索エンジンと似ています。ただし、インターネット検索は Web ページを、レジストリは業務プロセスを検索するよう設計されているのです。開発者の観点からすると、様々な基準にマッチするサービスを検出、公開する際に、レジストリを使用します。

注記

レジストリのパフォーマンスと信頼性を改善するには、Red Hat はレジストリの複製、連携を推奨しています。こうすることで、SPOF (単一障害点) とならないようにします。

1.3. レジストリ vs レポジトリ

レジストリのロールは、サービスの記録、メタデータの検出、事前定義済みカテゴリへのエンティティの分類を行うことです。レポジトリと違い、業務プロセスの定義、WSDL、または取引契約に必要なその他の文書を格納する機能はありません。レジストリは、アイテムのカタログであり、レポジトリはこのようなアイテムを含む格納領域です。

1.4. サービス指向アーキテクチャーのコンポーネント

「サービス指向アーキテクチャーは、エージェントが「サービス」となっている分散システムの一種です。」

注記

詳細の定義については、http://www.w3.org/TR/2003/WD-ws-arch-20030808/#service_oriented_architecture の W3C Working Draft を参照してください。
サービス指向アーキテクチャーの主要コンポーネントは、以下の通りです。
  1. 交換されるメッセージ
  2. サービスリクエスターやプロバイダーとして機能するエージェント
  3. メッセージのやり取りを可能にする共有トランスポートメカニズム
サービスとは、システムとユーザー間でやり取りを行うメッセージを指します。
サービス指向アーキテクチャーでは、サービスプロバイダー、ブローカー、リクエスターという、重要なロールが 3 つあります。それぞれの定義を以下に示します。
サービスプロバイダー
サービスプロバイダーは、サービスへのアクセス管理、サービスの説明の作成、サービスブローカーへの公開を行います。
サービスブローカー
サービスブローカーは、サービスの説明に関するレジストリをホストします。サービスリクエスターとサービスプロバイダーをつなぐ役割を果たします。
サービスリクエスター
サービスリクエスターは、サービスの検出を行います。サービスブローカーが提供するサービスの説明を検索することで、サービスを検出します。また、リクエスターは、サービスプロバイダーから取得したサービスをバインドします。

1.5. Universal Description, Discovery and Integration (UDDI) レジストリ

Universal Description, Discovery and Integration Registry (UDDI) は、web サービスのディレクトリです。設計時、実行時にクエリを実行することで、UDDI を使用してサービスの検索を行います。
UDDI Registry 内では、情報はページに分類されます。
  • グリーンページは、クライアントと提供のサービスをバインド可能な情報を提供します。
  • イエローページは、所属する産業をベースにビジネスを分類する際に利用します。
  • ホワイトページには、サービスを提供する企業の名前、住所、その他の連絡先など一般情報が含まれます。
UDDI は、サービスの説明を公開します。一般的な UDDI Registry には、uniform resource locator (URL) が含まれており、Web サービスの WSDL ドキュメントとサービスプロバイダーの連絡先情報を参照します。

1.6. Registry と JBoss Service-Oriented Architecture Platform

Registry は、JBoss Enterprise SOA Platform の主要な部分です。サービスを SOA Platform の ESB にデプロイすると、サービスのエンドポイント参照が Registry に格納されます。
Registry を自動的 (サービスをまず起動) または 手動 (ユーザーによる介入) で更新することで設定します。
Registry はサービスを一覧表示しますが、ステータスを判断することはできません。つまり、Registry に表示されているエンドポイント参照が有効であるか保証はありません (例えば、問題があるか、または有効でないサービスを指している場合があります)。これは、JBoss Enterprise SOA Platform にはライフサイクルモニタリング機能がないためです。そのため、管理者は手動で無効なエンドポイント参照を削除、更新する必要があります。
エンドポイント参照に関して Registry から警告やエラーメッセージを受け取った場合、サービスの担当者に通知するというのがベストプラクティスです。

重要

ESB サービスは、自身のエンドポイント参照を自動で作成します。このようなエンドポイントは、内部実装であるため、変更しないようにしてください。変更した場合は、Red Hat のサポート対象外となります。