第1部：サービスのポートフォリオ構築

Mastering SOAシリーズの第1部では、モジュラー・サービスのポートフォリオ構築に含まれる技術およびトレードオフを学習します。

関連するダウンロード・リンク Oracle SOA SuiteおよびOracle Services Registry

2006年9月公開

サービス指向アーキテクチャ（SOA）は比較的新しいものですが、多くの企業は、ビジネス・ニーズに沿ったソリューションを実装する方 法としてSOAアプローチを採用する必要があることを認識しています。 このアプローチのおもな手順は、再利用可能なサービスのポートフォリオを構築することです。

SOAは、新しいアプリケーションの設計、開発、統合の手法を根本的に変化させました。 また、企業アプリケーションを簡単に統合および再利用できるモジュラー型のビジネス・サービスとして開発することも可能にしました。

SOAのおもな利点は、ビジネスとITのギャップの解消です。 要件収集アクティビティの一部として、プロジェクトに関連する組織のおもな事業目標とビジネス要件および技術的な要件をマップすると、プロジェクトとビジ ネス要件の同期の実現に非常に役立ちます。

一般的にサービスのポートフォリオの構築を促進するには、ビジネス・ニーズにＩＴプロジェクトを割り当てるということを認識する必要が あります。 通常、必要なサービスを最初に決定してから、サービスと依存するリソース（特定のビジネス・ルールを定義するポリシーなど）を検出および分類します。 理想的な結果は、企業の変化するビジネスの要求を満たすために変更および再利用できる、一連のサービス指向ビジネス・アプリケーションです。

ビジネス・プロセス・オーケストレーション、ユーザー・インタフェース開発、セキュリティとパフォーマンスをサポートするインフラスト ラクチャなど、SOAの実装には多くの考慮事項がありますが、サービスのポートフォリオの取得が最初の論理ステップです。 "Mastering SOA"シリーズのこのステップでは、サービス・ポートフォリオを構築するフレームワークの概要を説明します。

通常、このようなSOAガバナンスは、次のような問題に対処します。

• サービスおよび関連リソースのライフ・サイクル管理
• 依存性の管理
• ポリシーの適用および管理
• セキュリティおよびランタイム・ポリシーの実施
• サービスの可用性
• サービスのプロビジョニング

管理構想と同様に、リスクを最小限に抑えることがおもな目標です。ここでは、ガバナンスを中心に組み込むSOA戦略を定義します。 SOAを管理しないと、次のような結果が発生する場合があります。

• サービス・レベルの要件に完全に準拠していないサービスが公開されてしまうプロセスの障害
• サービスの問題や停止により、ヘルプデスクや現場サービスへの問合せが殺到した場合のサポー ト・コストの拡大
• 縦割り型のビジネス・サービスが作成され、従来の緊密に結合されたアーキテクチャと同じ課題 が残ってしまう相互運用性の欠如
• おもなポリシーとサービスの関連付けの失敗による規制遵守違反
• データやサービスへ任意でアクセスできてしまうセキュリティ違反

サービスの検出

サービス・ポートフォリオを構築する最初の論理ステップは、必要なサービスを決定することです。 候補サービスを識別および検出する3つの実証済みの技術には、トップダウン分析、ボトムアップ分析、ビジネス・プロセス・トレースがあります。 排他的ではなく補完的にこれらの技術を利用し、サービス検出プロセスにすべてを活用してください。

最初のステップとして、組織の事業を機能"ドメイン"に分割することに焦点を当てたトップダウン分析を開始します。 この場合のドメインとは、顧客、製品、契約などの密接に関連する機能およびデータの論理グループです。

補完的な処理として、各ビジネス・イベントのライフ・サイクルを追跡し、ライフ・サイクルでイベントを処理するために必要なサービスを 検出します。 ビジネス・プロセス・トレースと呼ばれるこのプロセスは、イベントを処理するために必要なサービスを公開するだけではなく、純粋なトップダウンまたはボト ムアップ・アプローチで見落とされたサービス候補も公開します。

プロジェクトの配信に必要なサービスを識別する以外に、このビジネス・プロセス・ドリブンのアプローチは、完全な妥当性チェックを提供 し、特定のサービスの再利用性を最初に示します。

サービス検出の最終的な結果は、プロジェクトとしてもっとも必要な候補サービスを含む概念的なサービス・ポートフォリオです。

一連の候補サービスを検出したあと、設計、開発、および後続の実装をおこなうためにサービスを分類することが重要です。

分類は、機能、使用方法、構築、呼出しなどの基準に基づいています。 たとえば、インフラストラクチャ・サービス（DNS検索、電子メール）またはユーティリティ・サービス（変換）としてサービスを分類する場合は、機能に基 づく分類となります。

このような分類によって、同じ機能ドメインに属するサービスを識別できます。したがって、サービスの異なるクラスの管理および監視要件 とともに、標準およびベスト・プラクティスの定義を実行できます。 サービスを分類するプロセスでは、異なるタイプのサービスに適用する一連の再利用可能な標準ポリシーに変換できるビジネス・サービス・ルールも公開しま す。

サービスを分類する業界標準はありませんが、事実上の標準としてUniversal Description, Discovery, and Integration（UDDI）レジストリがあります。 UDDIによって、サービスだけではなくポリシーやXMLスキーマなどの関連成果物にもメタデータを設定できます。

たとえば、サービスの検出、管理、および制御を容易にするUDDIレジストリの次のタクソノミー・モデルを作成できます。

• サービス所有者および連絡先情報
• サービスまたは成果物の機能の説明
• "Version"や"Status: test | production | maintenance"などのリリース情報/ステータス
• サービスのタイプ（"Order Entry"）または事業区分（"Accounting"）
• "transactional | sub-transactional"、"synchronous | asynchronous"などの使用パターン/推奨
• 既存のサービスの再利用に役立つ予想されるエラー・メッセージ
• 関連ポリシー、XSL変換、およびXMLスキーマを含むサービスの依存性
• Webサービスの場合の抽象的および具体的なWSDLの場所と使用可能なサービス・エンドポ イント

サービスの粒度の決定

適切なレベルの粒度は、使いやすさ、再利用、および管理性を最大限に高めます。 通常、トップレベルのビジネス・ドリブン分析は、既存のニーズにマップされる高水準（おおまかな）サービスを公開します。 例として、おおまかなサービスは、ビジネス・プロセスにマップされる"Process Purchase Order"を表します。

理想的なSOAポートフォリオは、ビジネス・セマンティクスに直接マップされるおおまかなサービス・インタフェースでおもに構成されま す。 基礎になるインフラストラクチャに緊密に結合されていないので、高水準のサービスは、動的なビジネス環境で起動性があります。 また、おおまかなインタフェースを使用する場合、詳細や差異を意識しないで異機種の環境の他のサービスを使用して、アプリケーションおよびプロセスを構築 できます。

組織内の特定のユースケースを表すために使用されるサービスは、このようなサービスを使用するクライアント・アプリケーションの柔軟性 を高める詳細なインタフェースで実装されます。 ただし、このように柔軟性を高めると複雑さも増すので注意してください。

通常、ビジネス・ニーズを満たすサービス・ポートフォリオの一部として低水準のインタフェースを公開することは避けてください。 代わりに、一連の詳細なサービスの結合とおおまかなサービスとしての構成を検討してください。

詳細またはおおまかなサービスのどちらであるかよりも、ビジネスの価値を最大化するサービスが重要です。

サービスの取得

サービス・ポートフォリオを定義したあとに、実際のサービスを取得する方法を決定します。 社内でサービスを構築するかどうかに関係なく、サービスを取得するか、外部のプロバイダにホストされたサービスにサブスクライブしてください。

一般的に、組織の競争上の優位性を実現するプロセス・フローに役立つ重要なビジネス・サービスを社内で提供することが推奨されていま す。

サービス検出段階で識別された候補にマップされるサービスが社内にすでに存在している場合があります。 たとえば、組織がERPまたはCRMシステムを採用している場合、おもなインタフェース（顧客、注文、アカウント）は、すべてポートフォリオに追加できる サービスです。 また、企業内ですでに使用されているカスタム・アプリケーションでは、使用できるインタフェースを識別する分析を実行できます。

株価の相場など、より商品主導の機能を提供するサービスは、組織ですでに関係を確立しているビジネス・パートナーの外部サブスクリプ ションの候補となります。 ニーズを満たすサービスの検索を開始すると、すぐにサービスの分類の必要性が明らかになります。

候補サービスを識別する場合、サービスの管理に使用されるポリシー、サービスで使用されるメッセージ・タイプ、適切な形式に入力メッ セージと出力メッセージを変換するために使用されるXSL変換など、多くの対応する成果物も作成および管理する必要が出てきます。

これらの成果物のカタログと対応するサービスの関係を作成すると、ポートフォリオの構築に非常に役立ちます。 このタスクに不可欠なツールのUDDIレジストリを使用して、サービスおよび関連する成果物の完全なオンライン・ディレクトリを構築できます。

SOA管理の考慮事項

SOAインフラストラクチャは、監視や診断、外部化されたセキュリティ、一元化された監査とロギング、品質保証契約とポリシー管理など の管理機能のプラットフォームを提供します。 信頼性の高いメッセージ配信、ビジネス・ポリシーを取得および自動化するビジネス・ルール・エンジン、サービスを最適化するビジネス・アクティビティ監視 ソリューションを実行するエンタープライズ・サービス・バス（ESB）などの管理機能を拡張するため、多くのSOA固有のコンポーネントを使用できます。

仲介するWebサービス管理サーバーを使用すると、とくに効果的です。 この構成では、直接的なサービス・エンドポイントではなく、仲介してリクエストをルーティングできるように、利用者に公開されたプロキシURLでサービス が"仮想化"されます。 この一元管理されたプラットフォームを利用すると、サービスにポリシーを一様に設定し、1箇所でランタイム・ポリシーを実施できます。 また、サービス・メトリックと利用統計（サービス・ポートフォリオの状態を維持する重要なデータ）の取得が容易になります。

サービスの仮想化は、位置の透過性という利点も提供します。 プロキシを公開して、サービス利用者に影響を与えることなく基礎となるインフラストラクチャに変更できます。 仲介機能では、独自の仮想的なサービスツーサービスのエンドポイント・マッピングを維持するか、UDDIレジストリを使用して有効なサービス・エンドポイ ントを検出する必要があります。

結論

Dan Hynesは、おもにSOA関連製品を扱うOracle Javaプラットフォーム・グループの主要製品マネージャです。シリコンバレーの多くの企業で製品管理およびそのほかの技術に従事しています。

Salil Pradhanは、Oracle Fusion Middleware製品管理グループに従事するオラクルのSOAアーキテクトです。統合、ミドルウェア、そのほかの多くのソフトウェア・テクノロジーの分野で、15年に渡り従事しています。