本文へジャンプ

WebSphere Developer Domain > テクノロジー > 

SOA入門

第1回 SOAって何?

レベル: 初級者向け
日本アイ・ビー・エム株式会社
SWテクニカル・プランニング 牧野あすか
はじめてのSOA

今、IT業界ではSOA(Service Oriented Architecture)というキーワードが盛んです。
ITベンダーは口をそろえて、「SOAに対応した製品を・・・」とうたっています。
でも「SOAっていったい何?」そう思っているかたも多いのではないでしょうか?
当連載では、ともすれば抽象的でわかりにくくなりがちなSOAについて、やさしく解説していきたいと思います。


SOA(Service Oriented Architecture)とは?

まず、SOA(Service Oriented Architecture)とはこういう考え方でITシステムを構築していきましょうという概念であり、テクノロジーや製品ではありません。
SOAとは、コンピューターのソフトウェア機能を独立した「サービス」という単位で実装し、それらをくみあわせてシステムを作り上げる考え方です。これは目新しい考え方ではありません。SOAという概念はもともと古くからいわれていました。ではなぜ最近になって急に脚光をあびてきたのでしょうか?それには相次ぐ企業の統廃合や事業再編、市場競争の激化といった市場環境に対して、企業のシステムが柔軟に対応しなければならなくなったという背景があります。しかし、今日の企業システムはひとつの企業内ですら異機種環境が乱立する複雑なIT環境となっています。さらに相次ぐ企業合併や再編により、企業同士のシステムを統合しなければならないケースも増えています。そんな中で、「複雑化するIT環境をいかに統合するか」という課題に対する解決策として、浮上してきたのがSOAという考え方です。異機種分散環境における、ソフトウェアの統合技術の考え方は旧来もありましたが、インターネットの普及やオープンスタンダードの技術が発達したことにより、再びSOAが注目されるようになったのです。
SOAとは、コンピューターのソフトウェア機能を独立した「サービス」という単位で実装し、それらをくみあわせてシステムを作り上げる考え方であると先ほど述べましたが、ではSOAの特長とは何でしょうか?それは大きく3つあります。

  1. アプリケーションが業務処理などの単位でサービス化されていること、
  2. オープンで標準的なインターフェースでサービスが定義され、呼び出すことが可能であること
  3. サービスを組み合わせてアプリケーションを構築すること。

これだけだと抽象的でよくわからないので具体例をあげてみましょう。
非常に簡単な例ですが、在庫照会と在庫管理というふたつの機能をサービス化したとしましょう。図にある商品発注プロセス、オーダー受注プロセス、倉庫管理プロセスはそれぞれ在庫を照会し、必要に応じて在庫を減らしたり増やしたりする機能が必要です。これら3つのプロセス(ここではプロセスはプログラムと考えてください)が同じサービスを利用することによってITリソースを効率化することが可能となります。また在庫照会サービスの呼び出しのあと在庫管理サービスを呼び出すといった具合にサービスをつなぎ合わせてひとつの業務プロセスを作成することもできます。別のサービスが必要となればそのプロセスに柔軟に組み入れることも可能です。このような考え方をSOAと呼んでいます。

「サービス」の組み合わせによってアプリケーションを構成するシステム構築の考え方

上に戻る

SOAでいわれるところのサービスとは?

ではSOAで最も重要な要素となるサービスとは何でしょうか。SOAでいうサービスとは、業務の単位やプロセスを見据えながら、ある程度意味のある大きさにアプリケーションをコンポーネント化したものであり、外から呼び出せるよう稼働しているアプリケーションの機能です。アプリケーションの機能(プログラムでいうところの関数やメソッドに相当)は、インターフェイスがコンピューター処理できる形に定義され自立している必要があります。サービス自体は1つまたは複数のアプリケーションコンポーネントから成り立っています。サービスの実装は問いません。中身がJavaのクラスであってもEJBコンポーネントであってもCOBOLであっても構わないのです。肝心なのは明確に定義されたインターフェイスを持っていることです。インターフェイスとはサービス利用者とサービス提供者の間のきまりごとを記述したものです。例えばこのサービスを利用するためには引数はどういう型のものがいくつ必要で、戻り値はこういう型で、サービスの呼び出し場所はここですよといった情報をサービス提供者側はサービス利用者側に知っておいてもらう必要があります。ある機能をサービス化するときはこれらの情報をインターフェイス記述言語と呼ばれるものに記述しておきます。サービス利用者はこのインターフェイスさえ意識していれば、サービスの中身は意識することなく、サービスを利用し、自分たちのプログラムに取り込むことが可能なのです。ここでいうインターフェイス記述言語は当然コンピューターで処理できる形でなければなりません。そこで記述言語としてはXMLという技術が用いられます。代表的な記述言語としてはWSDL(Web Service Description Language)があります。WSDLについては別途次回紹介します。各サービスはさまざまな業務で利用されるケースが多く、再利用性が高いことが理想です。例えば在庫引当サービスは、商品表示画面で在庫数の表示をしたいときに商品受注システムが在庫確認サービスを呼び出して利用することもあれば、在庫不足を確認するために、商品発注プログラムが同じサービスを呼び出して利用することもあるでしょう。
サービスは多数のシステムから呼び出される可能性があるため、プラットホームやプロトコルに依存しないことが求められます。そこでWebサービスなどのオープンな標準技術を使って作っていることで、より多数のシステムから利用できるサービスを整備することができます。サービスはさらに別のサービスを呼び出して利用することもあります。例えば、在庫引当サービスが在庫確認サービスを呼び出すこともあるでしょう。



図 サービスの具体的イメージ



図 技術面から見たサービスの定義

上に戻る

最も簡単なSOAのパターン

では実際にSOAとはどういうイメージになるか、最も簡単なパターンで見ていきましょう。まずはあるひとつの機能をサービス化する例です。ここでは在庫管理システムの在庫照会機能をサービス化します。そしてこのサービスを商品発注プログラムから利用します。これまでは人間がいちいち在庫システムにアクセスし、在庫不足分を商品発注システムにデータ入力していました。商品発注プログラムでは在庫照会サービスを利用し、不足分を確認します。そして不足リストを作成し、従来どおり帳票出力し、相手先にFaxで注文を行います。ここでサービス化した在庫照会サービスは他のさまざまなプログラムからも再利用できます。



図 SOAの最も簡単な例

上に戻る

一歩進んだSOAのパターン

次に先ほどの簡単な例を一歩進んだ形にした場合を見ていきましょう。前述した簡単な例では商品の発注はFAXで行っていました。今度は在庫照会から商品発注、そして在庫の更新までをひとつのプロセスとして実行します。まずは在庫照会サービスを呼び出し、在庫に不足があれば商品発注サービスを呼び出し商品を発注します。商品発注が成功すれば今度は在庫更新サービスを呼び出して、在庫の値を更新します。ここまでがひとつのビジネスプロセスフローとなります。このように業務処理を基本要素に分けてサービス化しておくことにより、新規業務のためのITシステム作成時や、既存業務の変更なども、サービスの組み合わせの工夫で解決できるケースが多くなります。



図 一歩進んだSOAのパターン

上に戻る

SOAの価値

SOAを導入することの価値とは何でしょうか?もともとSOAの目的は、変化するビジネスニーズに対して、ITシステムをいかに柔軟に対応させるかという点にあります。個々のアプリケーションを柔軟に組み合わせることが可能なため、システムも市場の変化に迅速に対応することが可能となります。また、これらのサービスは特定のインフラに依存しないため、ベンダーやプラットホーム選択肢の幅が大きく広がります。また、IT面から見た場合、各サービスの実装はサービス利用者からは隠蔽されているので、利用者は各アプリケーションの内部の変更に関知せず、自分たちの業務範囲にのみ集中して開発が可能です。開発側は利用するサービスのインターフェイスのみを考慮していればOKです。また各アプリケーションは他システムと疎結合のため、システム開発が容易になります。さらにサービスの単位は従来のオブジェクト指向で作成されるコンポーネントよりも粒度が大きいため、再利用性がしやすく、開発生産性の向上を図れるという利点もあります。

では次回ではSOAを実現するための代表的な技術として「Webサービス」「BPEL」「ESB」についてご紹介したいと思います。


上に戻る

次頁へ
レベルマークについて

このページで紹介されている情報はレベル別にカテゴライズされています。

上級者向け
中級者向け
初級者向け
入門者向け

SOAポータル
詳細はこちら  

ビジネスの方もITの方も貴方の「SOA度」を試してみませんか?
詳細はこちら