PR

SOA(サービス指向アーキテクチャ)におけるサービス化は、あるシステムの一部、または全体を外部から呼び出すためのインタフェースを作成することを指す。インタフェースはどんなもので、どう作るのか。どんな既存システムもサービス化できるのか。ITに詳しくない事業責任者がどう利用するのか。これらの疑問に答える形で、サービス化を詳しく説明する。

日経コンピュータ2006年2月6日号の記事を原則としてそのまま掲載しています。執筆時の情報に基づいているため、社名や登場人物の肩書きを含め現在は状況が変わっていることがありますが、SaaSやEnterprise2.0の動向に興味のある方に有益な情報であることは変わりません。

 サービス化のための技術としては、システム連携技術のCORBAやWebサービス、Java関連仕様ではJava-RPCやEJBなどがあるが、インタフェース作成の手順はほぼ共通している。まず、インタフェース記述言語を使って、サービスの名称や所在、どんな入力に対してどんな出力をどのような形で返すか、通信プロトコルに何を使うかを決める。WebサービスならWSDL、CORBAならCORBA IDLと呼ぶインタフェース記述言語を使う。

 メインフレーム上のシステムをサービス化する場合は、通信プロトコルやデータ型を変換する「ラッパー」などと呼ぶプログラムを利用する場合もある。ソニックソフトウェアの「Sonic ESB」、ポーラーレイクの「PolarLake」といった、サービスを正しく連携させるためのミドルウエアであるESB(エンタープライズ・サービス・バス)製品が、ラッパーとしての機能を提供している。

連係機能を自動で作成

 WebサービスやCORBAの開発ツールでインタフェースを作ったら、それを基に、ツールが自動で連携に必要なプログラム(スタブやスケルトンなどと呼ぶ)を生成する。それらのプログラムを、サービスとサービスの呼び出し側に配置すれば、両者を連携できることになる。

 サービスはインタフェースが決まれば呼び出せるので、その処理がどんなプラットフォームで動作し、どんなプログラミング言語で記述されていても関係ない。したがって、複数システムが連携して行っている処理を一つのサービスとすることもある(図3)。

図3●サービスの実装例
図3●サービスの実装例  [画像のクリックで拡大表示]

 こうしたことから、「使いやすく、保守しやすいサービスの大きさ(粒度)を決めるのが難しい」との見方もあるが、主要ベンダーや先進ユーザーの意見を聞く限り、あまり神経質になる必要はなさそうだ。

 粒度を大きくしすぎるとインタフェースの規定が困難だし、小さくすると効率が悪い。そのため、自然に使いやすい大きさが決まるというのが根拠だ。富士通共通技術本部の薮田和夫プロジェクト統括部長は、「過去のソフト部品の多くは、システム面から効率性を考えていたので粒度を適切に決められなかった。しかしサービスは、業務を考慮することでおのずと粒度が決まる」と話す。

 日本IBMや日本BEAシステムズ、日立製作所、富士通など大手ベンダーは、サービスの大きさを決める方法論を提供している。

保守なし、ドキュメントなしでは無理

 どんな既存システムもすべてサービス化できるのか、との疑問も少なくない。「SOAのアプローチは理解できるし賛同するが、システムの内部構造を整理することが“変化に強くする”大前提ではないか」。概念データモデルに基づいて全社システムを再構築したKDDIの繁野高仁情報システム本部長はこう語る。「既存システムの内部構造を地道に整理してこなかった企業が、サービス化を簡単にできるわけがない」(同)。

 どのようなシステムがサービス化できないかについて、日本IBMの清水敏正WebSphereアーキテクトは「ジョブ・フローが非常に複雑になっているバッチ・プログラムなどは、解析が困難でサービス化するのは不可能だ」と指摘する。

 また、システム連携に詳しいウェブメソッドの森川衡プリンシパルSEは、「ソース・コードやドキュメントが残っていない場合は、手間がかかりすぎるのでサービス化する意味がない」と話す。プログラムの内部が複雑だったり、ドキュメントが紛失しているような場合は、無理にサービス化しないほうがよいということだ。

 こうした点で、意外と使いでがありそうなのは、パッケージである。パッケージが持つ機能それぞれをサービスとして組み合わせて使うわけだ。オリンパスはそのようにしてパッケージを導入した(図4)。

図4●オリンパスが定義したサービスの例
図4●オリンパスが定義したサービスの例
同社が作成したドキュメントを基に本誌が作成(記述内容は原文通り)  [画像のクリックで拡大表示]

 レガシー・システムとは違い、パッケージはドキュメントが整備されており、改変することは難しいが、内部構造も整っている。当然、既存システムと同様にすぐに使える。機能の一部またはすべてをサービスとして利用できるパッケージを選ぶ必要があるものの、このやり方も検討に値するといえるだろう。

ツール上でサービスを組み合わせる

 こうして作成したサービスに関する情報を、リポジトリで一元管理する仕組みが必要なのは、第1回で触れた通り。利用部門の担当者は、この情報をビジネス・モデリングに利用する。これがどんなイメージなのかも見ておこう。

 多くのモデリング・ツールでは、リポジトリに格納したサービスに関する情報をアイコンなどの形で表示できる。担当者は、例えば「受注入力」や「入金確認」などのサービスを画面上に表示させて、マウス操作でビジネス・プロセスの一つの要素として配置する。こうしてビジネス・プロセスを定義したり、追加・改変していく。

 操作エラーを検出する機能を備える製品もある。例えば担当者が、「受注入力アイコンの前段階に入金確認のアイコンを置く」といった操作ミスをすれば、ツールが警告をうながす。現実にはあり得ないビジネス・プロセスを実現してしまうことを防ぐのが狙いだ。

 以上の機能を持つモデリング・ツールとして、日本IBMが2005年12月に出荷を開始した「WebSphere Integration Developer」や日本BEAシステムズが06年中にも出荷を開始する「AquaLogic Composer」などの製品がある。