SOAとは
企業の情報システムは、ビジネス活動の変化や迅速化を支えることが期待されています。しかし実際にビジネスニーズに応じてシステムの変更や拡張を行おうとすると、影響範囲の特定が難しく改修が広範囲になったり、複数のシステムを人手で連携させている場合が多く、非効率で活用が属人的ノウハウに依存しているといった問題があります。
このような情報システムの課題を解決する手段として有効なのが SOA(Service-Oriented Architecture)です。SOAは情報システムを構築する手法とアーキテクチャの考え方です。その特徴は「サービス」というソフトウェアコンポーネントの考え方を導入し、情報システムを「サービス」の組み合わせによって構築することです。
SOAによる情報システム構築の考え方
SOAによる情報システム構築の基本的な考え方を図1に示します。
サービスとは、「発注」や「受入検収」、「返品」といった業務とソフトウェアの境界を一致させたもので、ビジネス活動を構成する業務を実現するために必要な機能とインタフェース(サービスI/F)を持つソフトウェアコンポーネントのことを指します。サービスは、サービスI/Fを介してメッセージにより入出力データの受け渡しを行います。
またビジネスプロセスとは、複数のサービスを組み合わせて連携させた一連の処理の流れを定めたものです。ビジネスプロセスはサービスI/Fを介してメッセージ授受を行うことにより、サービスと連携するとともに、サービス間のメッセージの流れを定義します。またビジネスプロセス自身もサービスを組み合わせた複合的なサービスとなり、サービスI/Fを持ちます。
これらのビジネスプロセスやサービスは、システムの設計段階において、業務の流れからビジネスプロセスを段階的に階層化していき、その中で抽出したサービスをソフトウェアコンポーネントに対応させたものになります。
また、サービスを利用するソフトウェアコンポーネントのことをフロントシステムと呼び、ビジネスプロセスを駆動する役割を持ちます。
SOAシステムパターン
SOAを用いたシステム構築において、フロントシステムとサービスの実現方法のバリエーションを分類したものをSOAシステムパターンと呼びます。システムの要件に応じて、フロントシステムとサービスの最適なパターンを組み合わせてシステムを実現することがポイントとなります。フロントシステムとサービスの主なバリエーションを表1に示します。
表1 SOAシステムパターン
# | 分類 | パターン | 内容 |
1 | フロントシステム | 対話型アプリケーション | 一人の作業者がアプリケーションを用いて業務を遂行する構成であり、当該アプリケーションは画面インタフェースにより作業者との間で入出力を授受し、サービスとの連携を実施する。 |
2 | 対話ワークフロー | 複数の作業者がそれぞれアプリケーションを用いて一連の業務を遂行する構成であり、複数の対話型アプリケーションを組み合わせた実現形態となる。 |
3 | イベント駆動 | 時刻やファイル到着といったイベントに応じて、サービスを駆動する形態である。 |
4 | サービス | ビジネスプロセス | ビジネスプロセスにより複数のサービスを組み合わせてサービスを実現する。サービス連携やメッセージ処理の流れは、SOAにおけるビジネスプロセス定義言語の業界標準であるBPEL(Business Process ExecutionLanguage)を用いて実現する。 |
5 | オンライン型アプリケーション | アプリケーションが問合せ応答処理によりサービスを実現する形態である。呼出元からの要求に応じてプログラム処理を実行して応答を返す(応答がない形態も含む)。たとえば Webサービスで実現するサービスは当パターンである。 |
6 | 対話型アプリケーション | #1と同様に、一人の作業者がアプリケーションを用いて業務を遂行する構成である。当該アプリケーションは画面インタフェースにより、作業者との間で入出力を授受するとともに、ビジネスプロセスとの連携のためのサービス I/Fを備える。 |
7 | 対話ワークフロー | #2と同様に、複数の作業者がそれぞれアプリケーションを用いて一連の業務を遂行する構成である。複数の対話型アプリケーションを組み合わせた実現形態となるが、アプリケーションの一部がビジネスプロセスとの連携のためのサービスI/Fを備える。 |
フロントシステムやサービスは、アプリケーションプログラムにより実現されます。サービスにはその実現形態として表1の#4~7のようなバリエーションがあります。またビジネスプロセスにより複数のサービスを組み合わせるパターンがあります。同様にフロントシステムにも実現形態としていくつかのバリエーション(パターン)があります。
SOAシステムパターンを組み合わせたシステム構築の例を以下に挙げます。
サービスオーダ管理業務への適用例
通信業でのサービスオーダ管理業務にSOAを適用した例を図2に示します。
これは、フロントシステムに対話型アプリケーションパターン、サービスにオンライン型アプリケーションパターンを適用した例です。顧客管理サービスや工事管理サービスなど複数のオンライン型アプリケーションをビジネスプロセスを用いて組み合わせることにより、ワンストップサービスを提供できます。顧客が申し込みWeb画面から必要な情報を入力することにより、顧客システムの設定から料金の設定まで一連の流れを自動化することができます。
SOAシステム構築手法
では、SOAシステム構築手法における基本的な考え方と、開発の全体的な流れを紹介します。
ビジネスプロセスとは、複数のサービスを組み合わせることで、ビジネス活動のIT化された範囲について、一連の業務の流れを定めたものであり、その上位の業務は、下位の業務の組み合わせにより業務内容を明確にすることができます。このことを業務の階層化と呼びます。階層化された下位の業務の組み合わせもビジネスプロセスで表現でき、ビジネスプロセスの階層化が可能となります。
サービスは先に述べたように、ビジネス活動を構成する業務と一対一に対応するソフトウェアコンポーネントと定義されます。図4は、一連の業務(アクティビティ)の流れを示すビジネスプロセスとサービスの関係を表現したものです。サービスにはアクティビティに機能を提供するためのサービスI/Fがあり、このサービスI/Fを通じてビジネスプロセスと連携します。サービスI/Fはサービスの顔であり、サービスが提供できる機能や必要な入出力データを定義する役割を持っています。
サービスが提供する機能の実装はサービスコンポーネントが担います。サービスコンポーネントを用いたサービスの実現形態には、前節のSOAシステムパターン(表1)で示すように、対話型アプリケーションパターンや対話ワークフローパターン、オンライン型アプリケーションパターンなどがあり、導入方法として新規開発や既存システムの再利用、パッケージ導入等の方法が利用できます。
アプリケーションには、フロントシステム側のアプリケーションもあり、ビジネスプロセスを通じてサービスを利用します。またサービスコンポーネント内で、さらに別のビジネスプロセスを呼び出すような多階層の形態も考えられます。
システム構築手法の全体像
SOAシステム構築手法全体の流れを図5に、全体の工程を表2に示します。ここで紹介する手法では、ビジネスプロセスに着目してサービスの抽出を行った上で、サービスを実現するコンポーネントの設計へ進める点に特徴があります。
表2 SOAシステム構築手法を構成する設計フェーズの概略
# | 区分 | 設計作業名 | 内容 |
---|
1 | 共通 | 新業務フロー作成 | システム化計画に基づく新業務フローを設計 |
2 | アーキテクチャ設計 | 非機能要件の洗い出し、非機能要件に基づくシステム構成の概略設計、システム方式の設計 |
3 | ビジネスプロセス | ビジネスプロセス設計 | 業務フローからビジネスプロセスを設計 |
4 | サービスI/F設計 | サービス粒度の決定とサービスI/Fの決定 |
5 | ビジネスプロセス詳細設計・実装 | BPEL、WSDL、XMLといった業界標準を用いてビジネスプロセスを詳細化および実装を実施 |
6 | ビジネスプロセスデバッグ | ビジネスプロセスデバッガを使用してビジネスプロセスのデバッグを実施 |
7 | アプリケーション | 画面設計 | 作業者の業務遂行に必要な画面、画面遷移を設計 |
8 | DB設計 | 必要なデータの分析、エンティティとその関連の抽出、データ論理仕様を設計 |
9 | コンポーネント設計・実装 | フロントシステム・サービスを実現するアプリケーションの設計と実装 |
これらの流れをあらためて説明します。
① 要件定義工程
要求内容を適切に定義する重要な工程です。
- 新業務フロー作成
- システム化計画に基づき、機能要件の洗い出しを行い、新業務フローを設計します。 このとき、システム化対象の業務に対応したサービス候補を決めておきます。また、各サービスの開発方針(新規開発、既存システムの再利用、パッケージソフトの導入)を決定します。
- アーキテクチャ設計
- 対象システム全体のアーキテクチャを設計します。要件定義工程では、非機能要件の洗い出しとアーキテクチャ概要の設計を行います。図5に示すように、基本設計工程、詳細設計工程にまで及び、非機能要件に対応するシステム方式の設計を行います。
② 基本設計工程
定義された要件を実現するビジネスプロセス、およびフロントシステム・サービスの機能を設計します。
- ビジネスプロセス設計(ビジネスプロセス)
- ビジネスプロセスを段階的に階層化し、サービスの粒度を見直します。新業務フロー作成で定義した業務フローから初期のビジネスプロセス(基本フロー)を作成します。次に業務的な視点でビジネスプロセスを階層化します。ここで業務の実施方法のバリエーションを洗い出し、サービス粒度の見直しを行います。
それと同時に、フロントシステムやサービスから呼び出されるユースケースシナリオを作成します。このユースケースシナリオは、後述するコンポーネント設計や画面設計・DB設計、サービスの実現形態の選択に用います
- サービスI/F設計(ビジネスプロセス)
- 実装の観点でビジネスプロセスを見直し、メッセージとして授受するデータの明確化などを行い、サービスI/Fを決定します。このサービスI/F設計でサービスの粒度の最終決定を行います。
- コンポーネント設計(フロントシステム)
- フロントシステム・サービスを実現するアプリケーションを設計します。
- 画面設計(フロントシステム)
- フロントシステムやサービスにおいて、作業者の業務遂行に必要な画面及び画面遷移の設計を行います。画面設計は、開発工程全体にわたって設計を継続します。
- DB設計(フロントシステム)
- フロントシステムやサービスにおいて扱われるデータの分析から、DBテーブルの設計までを行います。画面設計と同様に、開発工程全体にわたって設計を継続します。
③ 詳細設計、実装工程
ビジネスプロセス、フロントシステム・サービスについて、実装のための詳細な仕様を設計し、実装を行います。
- ビジネスプロセス詳細設計・実装
- ビジネスプロセス、サービス I/Fの各種基本設計仕様を元に、実装のためのビジネスプロセス定義、サービスが授受するメッセージの詳細定義等の設計を行います。
- コンポーネント設計・実装
- 基本設計工程のコンポーネント設計で設計されたプレゼンテーション層、ファンクション層、データ層の三層ごとに詳細な設計を行います。
次回は、こうしたシステム構築の流れに沿って、どのようにサービスを抽出し、ビジネスプロセスやフロントシステムを階層化していくかについて説明します。