背景
一流のニューイングランド大学では、旧式のシステムを置き換えるために、複数年にわたる戦略的なインフラの近代化プロジェクトを導入しています。それに加えて、全てのIT投資に対する利益を最大化しながらIT機能を強化しようとしています。そのプロジェクトは、ハードウェアのアップグレード、新しいソフトウェアの購入、開発グループやオペレーショングループのトレーニングを含みます。その近代化戦略の中心にあるのは、サービス指向アーキテクチャ(SOA) です。
SOAは、特定の技術というよりはむしろ、分散されたアプリケーション設計を目的としプラットフォーム全体に重点をおいた開発のためのアーキテクチャアプローチです。SOAの中心にあるものは、場所や所有者によらないソフトウェアサービスの定義と実装にあります。そして、それらは実行時にそれらを統治するためのインターフェースやポリシーを含んだ、システムやビジネスプロセスサービスに直接対応しています。SOAのメリットには、相互に作用するシステムやプラットフォームの間での疎結合、業界標準をベースとした至るところにある統合メカニズム、オンデマンドでのコンポジットサービスの作成サポート、経営効率を改善しながら既存資産を活用できるといったことなどがあります。
図1 サービス指向アーキテクチャ
伝統的なアプリケーション開発とデプロイからサービスベースのアプローチへの移行は、意味のあることで一朝一夕でできることではありません。パートナー、協力的なコンサルタントと共に作業して、大学のIT部門は、SOAのインクリメンタルな採用に対するロードマップを説明しました。インクリメンタルアプローチのメリットの一つは、投資に対する効果が即時であることと、短期・長期の大学の目的に一番うまく対処するように、変更要求を選択できることにあります。以降の記事では、1060 Research社のNetKernelを使用したリソース指向のエンタープライズサービスバス(ESB)の実装によるSOA採用プロセスを始めた6ヶ月間のプロジェクトについて説明します。
問題領域
より高い教育施設では、生徒、職員、卒業生から、オンラインサービスの提供に対する継続的な要望があげられます。彼らは、分かりやすいインターフェースや最新式の自動化されたプロセスを通して、彼らが２４時間いつでも情報にアクセスする生活に慣れています。同時に、委員会の舵取りや経費の管理をおこなうよう、経営者からの要望も強まっています。そのような事情から、新しい可能性に投資するときに、大学のようなより高度な教育施設のIT部門は、独創的かつ実用的でなければなりません。
大学のIT部門は、PeopleSoftのような商用の既製品(COTS)、顧客情報管理システム(CICS)の最高峰として作られたメインフレームのレガシーアプリケーション、Oracleアプリケーションサーバーポータルで作られた最新のJ2EE Webアプリケーションなどの幅広いアプリケーションをサポートしています。加えて、そのアプリケーションの多くが、サードパーティのアプリケーションサービスプロバイダ(ASP)と相互に作用し、データウェアハウス(DW)にヒストリカルインフォメーションを提供します。これらの全てが、新しいSOA のアプローチで統合され、協調されなければなりません。
歴史的には、その大学ではIBM MQとFTPを用いてビジネスシステムを統合していました。この伝統的なアプローチにより、多くのポイントツーポイント（P2P）の統合がおこなわれました。そして、これらのP2P統合により維持費がかさみ、コンシューマとプロバイダ間が密結合となってしまいました。しかし、既存の環境は、より一層の革新を可能にするための軽量なメッセージ交換の状態遷移アプローチ（MEST）を既に利用していました。メッセージバスアーキテクチャのサブタイプであるエンタープライズサービスバス（ESB）は、より結合度を減らした環境を提供します。配置にはより高い先行投資が必要ですが、システムの拡張に関するコストが線形で予測可能であり続けるので、ESBの価値は時間とともに指数関数的に増加すると確信しています1。
大学のＩＴ部門には、専門のアーキテクトとソフトウェアエンジニアの少人数のグループがあります。そして、彼らの多くは、在職期間の中でより高度な教育分野の専門知識を高めていきます。そのグループは小さいため、それぞれのメンバーは、サポートや管理を含む複数の役割を引き受けています。そのために、IT 部門は以下のことを達成するためのソリューションが必要とされます。:
- 再使用可能なサービスとコンポジットアプリケーションのメリットを享受することにによって、増え続ける顧客の要求に対処する
- P2Pの統合を低減もしくは排除する
- 既存資産や改善されたオペレーション効果のスキルを活用する
解決策
1. 概説
サービス指向アーキテクチャは、多くの異なるパターンとテクノロジーを使用して実行されます。従来のアプローチでは、WS-*の仕様を参照したパターンを使用していて、Apache ServiceMixのようなオープンソースのソリューションから、Cape ClearやSonic Softwareのような商用パッケージソフトまで、広範囲の技術製品から選ぶことが可能です。残念なことに、WS-*の仕様は常に流動的な状態にあり、 1300ページを超える詳細を会得しようとしている開発者を苦しめています。たとえば、全ての仕様に順守するには、SOAPサービスを実装するのに以下のステップとタスクを必要とします。:
- BPMN(Business Process Modeling Notation)を使用しているプロセスをモデル化する
- WSDLを使用したサービスインターフェースを定義し、UDDI(Universal Description, Discovery and Integration)リポジトリにサービスを登録する
- サービスレジストリからサービスにアクセスするためのBPMNを使用した、BPEL(Business Process Execution Language)スクリプトを生成する
- WS-Policyを使用したサービスへのアクセスを統治するポリシーを定義する
市場の中での商用のESB製品は、評価されています。そして、ITグループは比較的小さいので、決定事項はソリューションを探し求めることとなりました。そのソリューションとは、干渉の少ないシステムをもたらし、請け負い可能なITリソースの小さなグループが革新を呼び起こすことが可能で、単一のベンダーに依存した集中型のサービスオーナーシップモデルを強要しないことです。大学のドメインは、極めて流動的で、プロセスが変化し、アプリケーションが変化し、インテグレーションが変化します。それ故に、必要なことは、大学の本質を映し出している全体的な構造と戦略でした。
メッセージリクエストは、大学を横断する中央転送メカニズムとして既に確立されているので、RESTfulやリソース指向アプローチは、SOAを実装するために採用されていました。RESTは、HTTP、XMLといった広く受け入れられた小さな標準セットをベースとしており、非常に少ない開発ステップ、ツールキット、実行エンジンで可能です。SOAのRESTfulアプローチにおける主要な3つのメリットには、導入コストがより少ない、市場への投入時期がより早い、柔軟性のあるアーキテクチャがあげられます。リソース指向アプローチは、RESTfulアプローチを超えて、より深い拡張性を提供し、トランスポート独立な基盤を提供します。RESTデザインパターンは、HTTPの使用を推奨していますが、リソース指向のアーキテクチャは、HTTPでのサービス接続だけでなくJMSやSMTPといった転送手段もサポートしています。
CodehausのMuleのようないくつかのESB実装は、RESTをサポートしていますが、1060のNetKernelだけが、リソース指向のコンピューティングプラットフォーム 2 (即ち、ROC)をベースに構築されています。リソース指向コンピューティングの中心は、リクエストを送信する物理的なメカニズム(コード)から情報(リソース)に対する論理的なリクエストを分離することにあります。ROCを利用して構築されるサービスは、小さくて、単純、柔軟で、従来のアプローチと比較して少ないコードで済むということが実証されています。これは、技術プラットフォームを構築するための理想的な技術となります。
2. 技術基盤
NetKernelは、核となるエンタープライズサービスバス(ESB)の可用性、アドレッシング、ルーティング、データ変換を提供し、サービスレジストリオーケストレーションエンジンとして動作することのできるリソース指向ミドルウェアです。NetKernelは、豊富な機能を持ち、XML変換、キャッシュ管理、伝統的なWebサービスの提供を可能とするHTTP／JMS／SOAPエンジンを含む、複数のトランスポートプロトコルと共に、マルチスレッド処理などを提供しています。
概念的に、NetKernelは、URI（Universal Resource Identifier）アドレスによって特定されるリソースへのアクセスを提供します。すべてのURIアドレスは、論理アドレス空間の中で管理されます。 RESTベースのマイクロカーネルは、リソースに対するすべてのリクエストを取り扱い、アドレス空間からURIを解決してそのリソースの表現を返します。マイクロカーネルへのリクエストは、新しいリソースを作成、あるいは既存リソースの更新や削除も可能です。
物理的に、NetKernelシステムは、URIアドレスを通してパブリックサービスのインターフェースとリソースを公開するモジュールから構成されています。JavaのEARと似ていて、モジュールはソースコードとリソース設定を含んでいます。モジュールは、その他のモジュールの一般に公開されたサービスやリソースをインポートすることができ、それらはアドレス空間に組み込みます。インポートは、モジュールの論理名称を参照し、バージョン番号を指定することができるので、起動しているシステム内で、複数バージョンをいっせいに実行したり更新することができます。サービスリクエストは、システムの境界に備わっているイベント検知器であるトランスポートによって NetKernelにインジェクトされます。サービスコンシューマは、HTTPやJMSといったサポートされるすべてのトランスポートを通して、リクエストを送信することができます。
図2 技術基盤
HTTPは、ステートレスなリクエスト/レスポンスのアプリケーションプロトコルです。リクエストメッセージの構造は、コマンド、ヘッダー、ボディで構成されています。レスポンスメッセージは、ステータス、ヘッダー、ボディで構成されています。クライアントとサーバーはTCP(Transmission Control Protocol)ソケットを使用してこれらのメッセージを交換します。メッセージそれ自身が、暗号化とデジタル署名を利用してセキュアである間、クライアントとサーバーのインタラクションは、SSL(Secure Sockets Layer)プロトコルを利用したトランスポート層でセキュアにおこなうことができます。最終的に、クライアントはHTTPベーシック認証かHTTPダイジェスト認証スキーマを利用して認証されます 3。
Java メッセージサービス(JMS)のAPIは、非同期サービスを実装するためのプラットフォームを提供します。しかし、そのAPIはプロバイダを必要とし、今回はIBM WebSphere MQです。IBMのMQは、メッセージ指向ミドルウェア(MOM)で、アプリケーション間をキューをベースとした通信チャンネルを提供します。チャンネルは、ポイントツーポイントかハブ＆スポークの接続形態を使用します。メッセージトランスポートに加えて、MQではワークフロー、プロセスオートメーション、データー変換、モニタリング、管理をおこなうこともできます。
3. リソース指向サービス
リソース指向サービスは、リソースへのトランスポートに依存しないステートレスなアクセスを提供します。リソースは、情報を抽象化したものです。例えば、生徒の登録は抽象化で、WebページやXMLドキュメント、PDFファイルなどの表現形式を持つことができます。サービスは、リソース識別子やアドレスを使用しているそれぞれのリソース表現を公開しています。リソース識別子は、実際のところ、URI(Universal Resource Indicator)と関係があります。URIは、スキーマ(例えばHTTPやFTP)とアドレスの２つの部分で構成されています。URIの２つめの部分は関係です。アドレス/domain/account/45322が関係で、HTTPスキーマに関係がある場合は、http://domain /account45322となります。
図3 リソース指向のサービス概念モデル
サービスは、Create、Read、Update、Deleteというリソースを操作することのできるアクションのセットを定義します。加えて、特定のアクションがルールやビジネスロジックのトリガーとなります。リソースがリクエストされると、抽象的なリソースの物理的に不変な表現が返されます。異なる形式の表現として、例えばコンシューマの形式のようなビジネスロジックをベースとして返すことが可能です。例えば、大部分のバックエンドプロセスはXMLドキュメントを必要とし、フロントエンドプロセスではJSONオブジェクトを必要とするでしょう。サービスは、新しいリソースを作成する、あるいは既存のリソースを更新するための表現を受け取ることもできます。最終的には、サービスはリソースを削除するためのリクエストを受け取るでしょう。
図4 リソース指向のサービス相互運用モデル
トランスポートはシステムの境界に存在し、イベントを検知すると対応する内部のルートリクエストを発行します。例えば、HTTPトランスポートは、 URL(Uniform Resource Locator)のコンシューマのリクエストをリスンし、アクセスメソッド(例えば、GET、PUT、POST、DELETE)を指定します。そのURL は、内部の関連するURIに変換され、アクセスメソッドはアクションに変換されます。JMSでのリクエストの場合は、URIとアクションがメッセージヘッダーのパラメータとして渡されます。加えて、リソース表現が返される場合、戻りのキューのパラメータはヘッダーで指定されます。
RESTful システムでは、リソースへのアクセスはステートレスです。それは、それぞれのリクエストがメタ情報としてコンテキストを渡す方法を知っていなければならないということを意味しています。一般に、トランスポートは、ヘッダーとボディから構成されるメッセージ構造を定義しています。ボディがリソース表現を渡すのに向いているのに対して、ヘッダーはメタ情報を渡すのに向いています。例えば、リソース指向のサービスがHTTP上で公開されている場合は、認証情報はヘッダーの中で渡すことができて、サービスがJMS上で公開されている場合は、同様の情報は暗号化されたヘッダーパラメータとして渡すことができます。
リソース指向のサービスはMaven 4 を利用して構築され、NetKernelのモジュールとしてパッケージ化されます。Mavenは「プロジェクト」という単位でソフトウェアのビルドを管理をおこなうツールです。MavenプロジェクトはPOM(Project Object Model)のXMLによって定義されます。POMには、ソフトウェアの依存性、ビルドプロセス、デプロイ構造(例えば、JAR、WAR、EAR)を定義します。加えて、Mavenのプロジェクトは、Webサイトプロジェクトを生成したり、ソフトウェアをデプロイするのにも利用されます。この場合は、 MavenがNetKernelモジュールの中のサービスをパッケージ化し、レジストリに対してこれらのサービスに関する情報をパブリッシュします。
図5 リソース指向サービス開発
4. リソース指向のエンタープライズサービスバス(ESB)
リソース指向のエンタープライズサービスバス(ESB)は、NetKernelを使用して実装されました。NetKernelの中心は、RESTfulであることと、論理的なURIリクエストを物理的なコードのエンドポイントに分解し、リクエストを利用可能なCPUコアにスケジューリングすることに責任を持っているリソース指向のマイクロカーネルです。論理的なアドレスから物理的なコードへのマッピングは、アプリケーション構造の中で定義され、論理アドレスから物理コードへの実際のバインディングはリクエストの間だけ発生し、それ以降は破棄されます。
マイクロカーネルへのそれぞれのリクエストは再度バインドするので、リアルタイムに動いているコードを更新するといった機能を可能とし、システム管理者が、システムが実行中に論理アドレスと物理的なコード間の関連を自由に変更できます。パフォーマンスにおいては、実際に、指定しないでバインディングすることにより低下するのではなく、URIアドレスがNetKernelの内部キャッシュのキーとして振る舞うことで、むしろ強化されます。全てのリソースが再リクエストされ、依存性が変更されなければ、再処理する代わりにキャッシュされた表現が返されます。
リソース指向のマイクロカーネルを使用することで、いくつかの重要なメリットが得られます。初めに、サービスのインタラクションが物理的レベルよりも論理的なものとなります。これにより疎結合のインタラクションとなります。それ故、物理的な実装に変更がなされるときの、コンシューマやプロバイダに対する影響が減少します。次に、リクエストの結果がキャッシュされるので、サービスの構成とオーケストレーションにかかる全体コストが削減します。例えば、共通サービスに依存したオーケストレーションされたサービスのセットがあるとき、それに対応する共通サービスの物理コードはほとんど実行されないでしょう。最後に、マイクロカーネルへの内部リクエスト全てが非同期で、ホストサーバーにより多くのCPUを追加することで、処理を線形にスケールすることができます。
ESB は、サービスのプロビジョニングやセキュリティに対して主要な責任があります。サービスプロビジョニングは、HTTPやJMSのようなトランスポート上でコンシューマのためのリソース指向サービスを公開することを含みます。トランスポートは、外部URIとアクセスメソッドを内部のリソース指向サービスとアクションに対応づけます。トランスポートに関係なく、XMLドキュメントやJSONオブジェクトのようなリクエストのボディは、「param」という名称のパラメータとして渡されます。その結果、リソース指向サービスがトランスポート特有のロジックの詳細から切り離されるので、実際のプロトコルの追加が既存コードへの影響なく、いつでも追加することが可能です。
図6 リソース指向のサービスプロビジョニング
一方で、リソース指向サービスは、カスタムの基盤サービスやNetKernelによって提供されるコアサービスのセットに委譲します。NetKernel は、広範囲のコアサービスのセットを提供します。例えば、XMLやSOAP処理、クーロンジョブのスケジューリング、SMTPのインタラクションといったコアサービスがあります。そのコアサービスにより、リソース指向サービスを実装するために書かなければならないコード量が劇的に減少します。カスタムの基盤サービスは、より高度な教育ドメインで活用することのできる機能を公開するために使用されます。
ESBに対するそれぞれのリクエストは初めに認証され、その後で認可され、(場合によっては)監査されます。トランスポートは、ユーザー名とパスワードの組み合わせをベースとして受け取ったリクエストを認証し、セキュリティサービスに認可と監査を委譲します。認可には指定されたコンシューマが適切な権限をもっているかという検証も含まれます。権限は、関連するURIとアクションで構成されています。例えば、あるコンシューマが学生のプロフィールのリソースに対し、参照の権限があって更新・削除の権限がない場合は、対応するURIの/domain/student/identifier /profileによって特定されます。認可されていないリクエストは自動的に監査され、これらには指定されたコンシューマや権限をベースとした監査をするオプションが存在します。アカウント、権限、監査情報は、組み込みのHypersonicデーターベースに格納されます。
図7 リソース指向のサービスセキュリティ
要約
Actional やManagedMethodsのような、ランタイムサービスのガバナンスソリューション以外のESBを実装するためのミドルウェアは、全ての成功する SOAイニシアティブにとって重要なものです。ESB無しでは、組織は、単純にWebサービスを利用したポイントツーポイント(P2P)のインタラクションの数がコストの面で増加するだけです。ESBの構成や目的については広く意見が分かれるものの、サービスアドレッシング、メッセージ変換、メッセージルーティングなどの核となる機能のセットについて、大抵の場合は意見が一致します。NetKernelミドルウェアを使用してESBを実装することで、こういった機能や、サービス登録やオーケストレーションといったより進歩した機能が得られます。
NetKernel 製品は、大学でのリソース指向のESBの実装を可能としました。リソース指向のESBは、基本的にオープンスタンダードなエンタープライズの統合フレームワークです。このフレームワークにより、企業が高価なポイントツーポイントのインタラクションを削減あるいは削除することができ、新しい機能の導入に対する市場への時間を短縮することができます。さらには、フレームワークにより、WS-*をベースとした従来のエンタープライズ統合フレームワークよりも導入の初期コストがより低くなります。加えて、NetKernelとROCはサービス単位の基盤の統合をもたらすので、大学は(URIとして)ネットワークの端まで統合を推し進めることができます。そして、それらはより良いサービス管理とスケーラビリティへと変化します。要するに、このフレームワークにより、今までに例のないエンタープライズアーキテクチャを組織に素早く提供することができるのです。
6ヵ月未満で、3人のソフトウェアアーキテクトチームが、リソース指向のESBとNetKernelミドルウェアを使用して、多くの初となるリソース指向のサービスを実装しました。ESBの実装が功を奏し、大学のSOAの追加採用が始まりました。リソース指向のアプローチは、チームが既存の資産や技術スキルを活用することを可能にします。将来的には、大学のIT部門は、P2P統合を削減や削除をしながら再利用可能なサービスとコンポジットアプリケーションのメリットを享受することによって、増大するコンシューマの要求にも対処できる力を今持っているのです。
著者について
Jeremy Deaneは、Collaborative Consultingでテクニカルアーキテクトをしています。彼は、リーダーシップを取る立場で12年以上のソフトウェアエンジニアリングをしています。彼の専門領域には、エンタープライズアーキテクチャ、パフォーマンスエンジニアリング、ソフトウェアプロセス改善などがあります。さらに、彼は Drexel大学の情報システムで修士号をとり、最近ではホワイトペーパー「ドキュメントセントリックなSOA」を公開しています。