サービス・リポジトリーによるサービス管理とガバナンスの実現

サービスを共有するには、
適切な管理が重要 拡大図 SOAは、業務側とIT側の両側で「サービス」という共通の単位を切り口にして、システムを構築していく考え方です。サービスという単位をキーに構築していくことで、他のサービスとの組み合わせが可能となり、結果的にビジネスの変化に迅速かつ柔軟に対応することができるとされています。第9回目では、サービス品質を支える「SOAガバナンス」の重要性と、サービス管理を実施するIBM/SAPそれぞれのサービス管理製品と各製品のレポジトリ連携や使い分けのポイントについてご紹介します。
上記で述べたSOAの効果は、サービスがきちんと管理されてはじめて得られるメリットです。サービスを適切に管理しなければ、SOAそもそもの価値が失われてしまう恐れがあります。例えば、サービス検索の仕組みが確立していなかったために、同じ機能を持つサービスが複数開発されてしまい、それでは全体のコスト削減につながりません。また、サービス変更手順や責任者が確立していなかったために、ある担当者が他システムへの影響を知らずに変更してしまい、他の業務に問題が起きてしまう可能性もあります。

上に戻る

サービス・ライフサイクルと
SOAガバナンス・ライフサイクル
拡大図 IBMでは、モデル(Model)～アセンブル(Assemble)～デプロイ(Deploy)～管理(Manage)という、ライフサイクルでサービスを管理することを定義しています。そして、サービス・ライフサイクルの下レイヤーに位置付けられているのが「SOAガバナンス」です。
サービス・ライフサイクルでは、サービスの開発とデプロイというアクティビティーがフォーカスされますが、各フェーズにおけるアクティビティーの決定権とポリシーは、SOAガバナンスから提供することで統制を取ることができます。

「SOAガバナンス」という土台がしっかりしていれば、サービスは適切な品質を保ちながら管理されていくことになります。
「SOAガバナンス」という言葉は、SOAという考え方が出てきてから作られた用語で、既にあったITガバナンスの拡張部分と言えます。SOAガバナンスは、サービスが溢れかえり混乱を生じさせないよう秩序を保つと同時に、サービスの効率化や再利用の促進をもたらすものです。すなわち、ビジネス・プロセスに関する定義づけから、サービス開発のルールづくり、サービスを連携させるためのポリシーの策定、そして、アーキテクチャー計画やそれを推進するための組織体制や戦略まで含んだ包括的な概念です。
SOAを適用するメリットとして、「柔軟性の向上」「サービスの再利用によるコスト削減」などが挙げられます。こういった効果を得るためには、組織を超えた意思決定、トラッキング、可用性向上、コミュニケーション向上のためのフレームワークが確立されていることが必要不可欠ですが、このフレームワークこそがSOAガバナンスです。
SOAガバナンスの重要性を理解しなければ、SOA適用のメリットを最大限に得るのは難しいとさえ言えます。

上に戻る

SOAガバナンス・ライフサイクル
の各フェーズ 拡大図 この節では、サービス管理の基盤となるSOAガバナンス構築の流れについて簡単にご紹介したいと思います。IBMでは、SOAガバナンスを構築するアプローチを、計画(Plan)～定義(Defile)～実施(Enable)～測定(Measure)の4つのフェーズに分けて考えています。また、ガバナンスは継続的な改善活動であり、この4フェーズで構成されたライフサイクルは、繰り返し行われる必要があります。

各フェーズついて簡単に説明します。

• 計画(Plan)　ガバナンス・ニーズを確立
  計画フェーズでは、ガバナンスの必要性を検証します。具体的には、現状のITガバナンスの評価と、SOAに関するビジョンや戦略の更新を行います。組織をまたがった決定プロセスなども調査します。企業が受け入れるガバナンス・モデルを定義できるかどうかは、組織に大きく依存します。これらをドキュメント化した上でハイレベルな計画を作成します。
• 定義(Define)　ガバナンス・アプローチの設計
  定義フェーズでは、ガバナンス・プロセスを定義します。組織的なメカニズム、決定権限、ガバナンス効果測定の指標、ビジネス・ドメイン、ビジネス・ドメインのオーナー・・・など、ガバナンスに必要な項目を決定し、ポリシーおよび強制力を働かせる仕組みを定義していきます。Center of Excellence(CoE)の必要性もここで検討します。
• 実施(Enable)　ガバナンス・モデルの実施
  実施フェーズでは、計画されたガバナンス・モデルを業務に適用していきます。定義フェーズで決定した内容をすべてこのフェーズで実現化します。企業全体に対して教育を行い、普及させていきます。
• 評価(Measure)　ガバナンス・プロセスの監視と管理
  測定フェーズでは、ガバナンス・モデルの導入による効果を測定し、必要に応じて対処します。定義フェーズで定義した指標をもとにデータを集約し、ガバナンスの効果を理解することを目的としています。

以上が、SOAガバナンス構築の流れになります。SOAガバナンスが企業全体に浸透していれば、企業全体のプロセスおよびサービスが整備されているはずなので、効率的なサービスの再利用や短期間での変更が可能となるのです。

関連情報

• Advancing SOA Governance and Service Lifecycle Management (US)

  SOAガバナンスを進めるための具体的な手順についてはこちらをご覧ください。

上に戻る

企業におけるSOAガバナンスの重要性をここまで述べてきましたが、「では、それをどう管理するのか」という課題が次に浮かび上がります。ガバナンスの実体であるポリシー、原則、標準、手順を管理するツールが必要となります。
ここでは、前節で述べたSOAガバナンス・ライフサイクルの各フェーズをサポートするために、IBM、SAPそれぞれが提供しているツールを一覧にしました。両社ともに、管理したいカテゴリーによって、さまざまなツールを用意しています。特に、今回のトピックはサービス管理となっていますので、サービス管理ツールとされているIBMのWebSphere® Services Registry and RepositoryとSAPのEnterprise Services Repository and Registryについて、次節から詳しく見ていきます。

上に戻る

SOAガバナンスが整備され、適切なポリシー、原則、標準、手順が定まった上で、次は、組織という枠を超えたオーナー間でサービスに関する情報を共有するためのツールが必要となります。サービスは、業務とIT両方の観点から語られなければならないので、業務担当者とIT担当者の両者から見て理解ができる台帳のようなものが必要となってきます。また、サービスはデプロイされた後に、監視・管理されるフェーズに入るため、ライフサイクル管理に関する情報も同時に管理しなければなりません。ライフサイクル管理には、再利用性やコスト削減を実現できているか、確認するための評価タスクも含まれます。
そこで登場したのが、サービス・レジストリー&リポジトリーです。サービス・レジストリー&リポジトリーでは、下記のようなサービス管理のための機能が提供されます。

• サービスのメタデータ管理
• ライフサイクル管理
• 種別システム
• 影響分析
• 変更管理
• 妥当性検証
• 照会

上に戻る

ES Repositoryと
Services Registry 拡大図 SOAガバナンスで管理すべき項目をどのツールで管理していくかは、ベンダーごとに異なっています。ここでは、SAPのツールであるSAP Enterprise Services Registry and Repository(以下、ESR)についてご説明します。
ESRはES RepositoryとServices Registryによって構成されています。ES Repositoryでは開発に必要となるオブジェクトを定義することができ、そして、それらを保管する機能を持っています。この機能により、さまざまなシステムで稼働するアプリケーション・サービスのオブジェクトを一元管理することが可能となります。一方、Services Registryはサービスを見つけ出すための電話帳のような機能を持っています。Service Registryではアプリケーション・サービスを公開すると同時に、サービスを検索・分類することができるため、ユーザーがサービスを公開/発見することが容易になり、再利用性を高めます。

例えば、ESRのES RepositoryとServices Registryの機能を併せて使うことで、既存のオブジェクトやサービスを使って開発を行い、それをサービス化して公開したり、また既存のサービスを発見して再利用したりすることができます。その結果、無駄な開発を減らすというSOAアプローチが実現できます。

上に戻る

ES Repositoryは、SAP NetWeaverのEAIツールであるProcess Integration(またはeXchange Infrastructure)のIntegration Repository部分が拡張されたものです。サービス・インターフェースやグローバル・データタイプ(GDT)などのオブジェクトを保管することができます。ソフトウェア・コンポーネント・バージョンという単位の下にフォルダを作成することができ、オブジェクトを階層構造で保管することができるため、ビジネスとして意味のある単位で階層を作っておけば、既存データの発見が早まり、再利用しやすくなります。
このほかに、プロセス・コンポーネント・モデルといった拡張オブジェクトも定義することができ、開発オブジェクトとのリンクを持たせて保管させることができます。プロセス・コンポーネントは、モデル駆動型開発をサポートするモデリング環境です。ここで定義したモデルからインターフェース定義への関連付けを行うことができ、モデル上の該当オブジェクトをダブルクリックすることで定義画面に飛ぶことができます。
先にも述べましたが、ES Repositoryを使用するメリットは、サービスにかかわるオブジェクトを一元管理できるという点です。WSDLで記述されていれば、SAPシステム以外で稼働しているサービスのインターフェースも、外部定義としてインポートすることが可能です。一個所ですべてのオブジェクトを管理できるということは、コンポジット・アプリケーション開発効率向上につながります。
下記は、ES Repositoryで管理されるオブジェクトの例です。

この他、下記のようなオブジェクトも保管できます。

• インテグレーション・シナリオ
• オペレーション・マッピング
• 実行可能インテグレーション・プロセス(BPEL)

上に戻る

Services Registryから
サービスをコンシュームした
開発の流れ 拡大図 Services Registryは企業のサービスを集中的に保管する場所です。サービスを公開/発見するための標準技術であるUDDI3.0が採用されています。Services Registryは、そのサービスが、どこにあるのか、どういうステータス(モデル作済、設定済、導入済、など)なのか、といったサービスの属性情報を知りたい場合に役立ち、SOAランドスケープのビジビリティーを向上させます。
また、レジストリー機能に加えて、検索を容易にするための分類機能も持っています。エンタープライズ・サービスのようにSAPから提供されているWebサービスは事前定義された分類にカテゴライズされていますが、後から必要となった分類を追加作成することも可能です。分類は、ビジネス的な意味を持つ単位で作成することにより、後にビジネス・シナリオに沿ったコンポジット・アプリケーション開発をする際に役立ちます。

Service Registryは、使用できるWebサービスがあるのかを検索したい開発者と、異なるシステム間にあるサービスをつなげるためにエンドポイントを調べて接続設定をする管理者などが使用します。サービスはSAPシステムのもののみではなく、non-SAPシステムのものも含んでいます。
Services Registryの検索画面では、キーワードからサービスを検索することができます。
1000個以上あるSAP提供のWebサービスであるエンタープライズ・サービスと、自分で登録したサービスなどを、単一のレジストリから検索することが可能です。

また、分類に割り当てられているものに関しては、業務カテゴリーから検索していくこともできます。エンタープライズ・サービスは、あらかじめ分類されているので、導入後に自分自身でその分類を定義していく手間はありません。

サードパーティー・サービスの
Publish 拡大図 Services Registryでは、SAPだけでなくサードパーティーのWebサービスを公開する機能があります。下記画面のようにエンドポイントWSDLを入力し、Publishボタンをクリックするだけで公開することが可能です。(ただし、現段階では、認証を必要とするものは公開することができません)

下記画面では、SAPの開発ツールであるVisual Composerから、Services RegistryにあるWebサービスを発見してコンシュームしています。

• Services Registryによるサービスの発見と利用 （zip, 2.04MB）
• Adobe® Flash® Player が必要

再利用可能なサービスを発見できるのか、そして、発見した後に複雑な作業なしに開発ツールに取り込んで新しいサービスを構築できる環境が整っているのかどうか、このあたりの環境整備がSOA適用の成功の鍵を握っていると言えます。

上に戻る

WebSphere Service Registry and Repository(WSRR)は、WSDL(Webサービス定義文書)や、XSD(Xmlスキーマ定義文書)などを管理するための、IBMのソフトウェアです。WSRRは単にWSDLやXSDを管理するだけではなく、サービスの所有者、ガバナンス状態、サービス・レベル、関連するサービスなども管理することができます。それにより、SOAで重要となる"再利用性の向上"のために必要な、サービスのガバナンス管理、サービス変更の影響分析、ライフサイクル状態が遷移した際の通知などの機能を提供します。

WSRRのガバナンス管理 拡大図 右の図は、サービスのガバナンス状態の設定画面と、ガバナンス状態参照画面です。

デフォルトのガバナンス状態遷移
拡大図 WSRRには簡単かつ迅速にガバナンス管理をスタートできるよう、デフォルトでガバナンス状態が設定されています。また、必要に応じてカスタマイズすることも可能です。

サービス変更時の影響度分析
拡大図 右の図は影響分析画面となります。サービスに変更が発生した場合、その変更がどこに影響を与えるのか容易に確認することができます。

WSRRのグラフィカルビュー
拡大図 WSRRでは各文書の関連性がグラフィカルに表示されるので、開発者はWSDLがどのようなエンドポイントを持ち、どのようなインターフェイス・パラメーターなのかという情報を簡単に理解することができます。右の図がWSDLをグラフィカルビューで表示した例となります。

上に戻る

WSDLと
パワーポイントファイルを
関連付け 拡大図 WSRRはWSDLなどの他に、テキストファイル・エクセルファイル・パワーポイントファイルなど、どんな形式のファイルでも取り込むことができ、それらのファイルとWSDLなどを関連付けておくことができます。
Webサービスを利用する場合、WSDLだけでは具体的なサービスの内容が分からないことがよくあります。例えば、SAP Enterprise Serviceはパラメーターが多く、何をパラメーターにセットすればよいのかほとんど分かりません。WSDLが公開されているだけではWebサービスを利用することはできないということです。そのような場合、パワーポイントでWebサービスの仕様書をWSRRに登録し、WSDLと関連付けておくことで、Webサービス利用者は、WSDLが提供するサービスがどのようなもので、どうすれば利用できるのかということを知ることができます。このような仕組みがあることで、Webサービスの再利用性が向上します。

上に戻る

追加プロパティーによる
検索結果 拡大図 WSRRで管理する文書には、プロパティーというパラメーターがついていますが、標準で用意されているプロパティーの他に、管理者によって独自のプロパティーを追加することができるようになっています。例えば、各文書にオーナーというプロパティーを追加して、オーナー名を登録しておくことで、あるオーナーが所有している全文書を検索することができます。追加できるプロパティーに制限はありませんので、企業がサービス全体を取り決めた管理方針に従って、柔軟に管理の仕組みを構築することが可能となっています。

上に戻る

WSRRとSAP ESRの連携 拡大図 SAP ESRは、SAPシステムで標準提供されているWebサービス、SAP Enterprise Serviceを開発、管理するための製品です。WSRRでは、このESRで管理されているEnterprise ServiceのWSDLを、自動で取り込むことができるため、Enterprise ServiceをWSRRにマニュアルで登録する手間を省くことができます。また、SAP ESRの他に、UDDI準拠のレジストリーであれば、それらも同様に連携することが可能となっています。

上に戻る

WSRRはEclipse V3.0.2以降のJava®開発環境に対して、プラグインを用意しています。そのため、どのベンダーのJava開発環境(Eclipse V3.0.2以降)でも、Webサービスを利用するJavaプラグラムを開発することができます。以下の図がIBM製のEclipse製品(Rational Application Developer : RAD)と、SAP製のEclipse製品(NetWeaver Developer Studio : NWDS)で、WSRR Eclipseプラグインを利用して、WSRRに登録されているWSDLを利用している図となります。

実際に、WSRRを利用したメディエーション・モジュール開発の動画をご覧いただきます。このデモは、WSRRにインポートしてあるSAP Enterprise Serviceを利用して、簡単にメディエーション・モジュールを開発できるところと、開発したメディエーション・モジュールからSAP Enterprise Serviceを呼び出せるところを、確認していただけます。

• WSRRによるSAP Enterprise Serviceの利用 （zip, 3.11MB）
• Adobe Flash Player が必要

上に戻る

WSRRとESRの使い分け 拡大図 SAP ESRはEnterprise Serviceを開発、管理するためのツールであり、特にABAPスタックでのWebサービスを開発、管理するためには、必須となっています。しかしながら、企業全体のサービス・リポジトリーを考えた場合、サービスのオーナー、サービスの利用者、サービスの管理者など、誰もが容易にアクセスできるツールでなければ、常にサービスを最新の状態に保つことは難しくなってしまいます。その点で、ESRは開発寄りの傾向が強いツールであり、サービス管理者がサービス全体を管理するための機能が弱いところが見受けられます。例えば、サービスのオーナーは誰で、どのアプリケーションでサービスが利用されているかなどを知ることができません。そのため、サービスの修正依頼が発生した場合、影響がどの程度なのかをESRだけの情報ではつかめないということになります。
WSRRはWSDLだけの管理ではなく、サービスを利用しているアプリケーションも関連付けておくことができますので、サービス変更時の影響範囲なども容易に判別することができます。
WSRRとESRはそれぞれに特徴がありますので、その特徴を生かして使い分けることを推奨しています。SAP Enterprise Serviceを社内で利用するかどうかにより、SAP ESRの利用を検討します。

上に戻る

IBM社内のリポジトリー構成
拡大図 IBMは社内システムに、SAPシステムおよびSAP Enterprise Serviceを利用しています。そのEnterprise Serviceとnon-SAPシステムのWebサービスを統一的に管理する仕組みとして、WSRRとSAP ESRを連携して利用しています。

• IBM/SAPハイブリッドSOAソリューションのご紹介 INDEXはこちら

上に戻る