【第111回】ビジネスプロセスSOA

昔からコンピューター業界は新しい3文字のキーワードを発信して市場を作るマーケティングを行ってきた。SCMとかEUCとかBPRという類である。
ここ2,3年のトレンドからすると、一番ホットになりつつあるキーワードはSOAであろう。
SOAは、Service Oriented Architectureの略で、ソフトウェアの新しい概念の1つである。日本語では、“サービス指向アーキテクチャ”と言い、オブジェクト指向アーキテ クチャ(OOA)の親戚だと勘違い(美しい誤解?)をしている人もいるようである。

SOAとは何かについては、以下の引用を読んでいただきたい(以下引用)。



■サービス指向アーキテクチャ
ソフトウェア工学において、サービス指向アーキテクチャ(サービスしこうアーキテクチャ、Service-Oriented Architecture、SOA, 「エスオーエイ」あるいは「ソーア」と発音)とは、大規模なコンピュータ・システムを構築する際の概念あるいは手法の一つ。業務上の一処理に相当するソフ トウェアの機能をサービスと見立て、そのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉である。業務処理の変化をシス テムの変更に素早く反映させたいという需要に応えうるものとして、2004年頃からIT業界において注目を集めている。

SOAの必要条件
SOAに必要とされている条件は、次のような事柄である。
業務上の一処理に相当する単位でソフトウェアが構成されていること。SOAにおけるサービスとは、その構成単位のことである。プログラム上の部品ではな く、たとえば「決済する」「在庫状況を照会する」などの単位で一つのサービスとすることが求められる。どの程度の規模 (粒度) を一つのサービスとするが良いのかについては様々な議論がある。

(中略)

SOAへ至る経緯
SOAに通じる考え方や技術は古くから存在している。オブジェクト指向やコンポーネント指向は、決められたインタフェースに従ってソフトウェアの一部分を カプセル化、部品化し、それを組み合わせて全体を構成するという考え方を基本としている。また、分散オブジェクト、メッセージング、EAI (Enterprise Application Integration) などの技術を使用し、ネットワークを介してソフトウェアを連携 (疎結合) させるといったことは、大規模なシステムにおいてはすでにある程度実施されている。
ただし、オブジェクト指向やコンポーネント指向においては、主にプログラム上の部品をソフトウェアの構成単位としており、業務処理の変化をシステムの変更 に素早く反映させたいという視点においては単位が小さすぎる、とされている。(もっとも、単位の大きさ (粒度) は元来任意であり、オブジェクト指向やコンポーネント指向における部品の粒度を業務処理のそれに合わせたものがSOAにおけるサービスであると捉えること もできる。)
また、従来のシステム連携技術は、特定のソフトウェア基盤の使用を前提としているか、あるいは連携させるために必要な作業や手順が煩雑である。こうしたこ とから、システム連携のスピードやコストにおける問題点が指摘されていた。このような問題を解決するための技術あるいは概念として、2000年頃から Webサービスが提唱されている。
ただし当初のWebサービスは、現在のSOAと同様の構想がすでに提唱されてはいたものの、実装技術としてはWebを介したソフトウェアの連携自体に主眼 が置かれていた。また、連携する個々のソフトウェア (サービス) をシステム全体の中でどのように位置づけるのか (サービスの粒度の目安を何に置くのか)、多数のサービスを連携させる複雑なトランザクション処理などをどのように設計、実装するのかといった事柄が、課 題として残されていた。その後、Webサービスの概念や技術の拡張に伴い、2004年頃から、「Webサービス」に代わって「SOA」がキーワードとして 注目されるようになった。
(以下省略)

以上、「サービス指向アーキテクチャ」フリー百科事典『ウィキペディア(Wikipedia)』(http://ja.wikipedia.org/wiki/SOA)2008年1月18日 (金) 07:32時点のものより引用



この業界の通例で、こうした抽象的な概念が提唱されると、各社各様の解釈による製品や、いろいろな立場からの定義や解説が出版されて、何が本質なのかさっぱり判らない状態になるのである。
オブジェクト指向のときも初期の頃に、訳が分かっていなかった米国の大先生が、オブジェクトのたとえ話に犬の話を例にして、話を思い切り発散させてしまったために、ソフトウェア工学のコンポーネント技術が宗教じみた森羅万象を覆う大概念に敷延されてしまって収拾がつかなくなったことがあった。
この難解さを克服するためにいくつものセミナーや本が出版されることとなったことは記憶に新しい。

実はSOAの中で最も議論になっていて抽象的で発散している問題がある。
それは、SOAのSの“サービスとは何か”という問題である。前述のWikipediaの解説によれば、サービスとはプログラム上の部品ではなく、例えば 「決済する」「在庫状況を照会する」などの単位である。とあるが、このように、“~のようなもの”としてしか解説されていないために余計な解釈が量産されて市場が混乱するのである。
ともかくも言えることは、SOA におけるサービスとは人間がアプリケーションの機能として認識できる粒度のモジュールであることは確かなようだ。

この流れがなぜ生まれたかというと2つの側面があると筆者は考えている。

1つは、90年代から始まったネオダマ(ネットワーク、オープン、ダウンサイジング、マルチメディア)のインフラが草創期を経て成熟期に達してきて、マシンはIBM、OSはリナックス、データベースはオラクル、ミドルウェアはフリーウェア、アプリケーションはJava、というように1つのシステムを構成す る組合せが完全に自由になったことに由来する。
このことによって、エンドユーザーは大幅なハードウェアのコストダウンや通信費(ネットワーク費)のコストダウンを享受することとなった。
それでは、それまではどうだったのかというと、ハードもOSもミドルウェアもデータベースもネットワークもアプリケーションもメインフレーマー(IBMやNECのことです)がクローズした環境で提供したのである。
それゆえ、ハードウェアをIBM製にすればそれに伴うすべてのインフラはIBM製になったわけである。そのこと自体はコスト高につながるため、ユーザーはマルチベンダー化やオープン化に走って今日のようになったといえる。
ところが、このオープン化はよい面ばかりではなく、マイナス面も当然あるのである。
昔はすべてのインフラが1つのメインフレーマーからの提供であったので、データベースとミドルウェアの不整合とか、OSとメモリの不整合のような組合せのトラブルやリスクはなかった。少なくとも、各レイヤーの組み合わせによる不整合はメインフレーマーが全て面倒を見たのである。
これが、ユーザーが自己責任で組み合わせたインフラになると、その組合せの不整合によるトラブルはユーザーが自ら負わなくてはならない。OSと言語とデータベースとハードウェアの専門的な知識が必要となるのである。それを各メーカーは自分達の領域しかサポートしないので、レスポンスが悪いとか、マシンが突然ダウンするというような現象に対しての問題の切り分けや対策はユーザーの技術力で行わなければならないのである。これは大変な負担であるし、技術的にも不可能に近いことである。
そこで考え出されたのがSOAなのである。
SOAというインフラのもとにアプリケーション(サービス)を提供することによって、少なくとも全体の整合性をある程度保障出来るようになるのである。ハードベンダーはその基盤インフラをSOA対応として発表している。
これがSOAの出現した背景の1つであると筆者は考えている。

2つ目の背景は、ERPに代表されるような大パッケージの過剰機能の問題である。これを料理に例えてみよう。
あるフレンチレストランの話である。その店はコース料理が1つしかなく、しかもその皿の数が30もあって(まるでどっかの3つ星レストランのようですが) とても食べきれない量であるし、値段も35,000円もかかる。客は2,3の料理を食べて10,000円位であげたいのだが、今のメニューでは対応できない。そのリクエストを聞いた料理長が、お客さんが好きなメニューを好きな量だけ食べられるようにアラカルトのメニューを用意したのである。
これによって、小食なお客さんは3皿のみを選んだり、野菜が好きな人は野菜料理、ジビエが好きな人はジビエ、フォアグラが好きな人はフォアグラというように、お客さんのニーズに合わせて料理を組み合わせて食事を楽しめて、しかも値段もリーズナブルになったのである。
このアラカルトメニューを提供するインフラがSOAである。そして、その料理そのものがSOAの“サービス”に相当するわけである。
ユーザーの好みに合わせて必要なサービスを組み合わせてソリューションとして活用する仕組みを提供するインフラがSOAなのである。これが実現されれば、ユーザーは不必要な機能やプログラムを購入する必要がなくなるのである。
例えば、在庫管理だけをやりたいのに、生産管理パッケージを丸ごと購入して、受注や生産計画や購買や工程管理の機能に無駄なお金を支払う必要がなくなるのである。この概念をビジネスプロセスSOAと呼ぶ。

ビジネスプロセスSOAとは、一本一本のプログラムをサービスの最小単位として定義し、Webの環境でそれらを自由自在に組み合わせることによって、実現されるソリュ-ションの総称である。
このサービスによって従来のパッケージの枠組みはより自由なサービスの集合体へと再編される。しかもそのサービス群はマシン、OS、データベースの制約を受けず完全にオープンな環境で提供されるのである。
ビジネスプロセスSOAにおけるサービスとは、まさにプログラム1本1本を指す。ユーザーは業務パターンに応じたサービスを必要な分だけ組み合わせて購入できるのである。
ビジネスプロセスSOAをみれば、弊社がSOAの“サービス”という単位を設計や試作や購買や生産管理の分野でどのように考えているのかが分かるはずであ る。業界の議論に一石を投じる試みでもある。この“サービス”を曖昧にしてSOAを議論することは単なる抽象論でしかなく、“サービス”の粒度に応じて仕 掛け(インフラ/例:BPELのような)も変わってくるので、“サービス”に関する議論や定義を曖昧にしてはいけないと思うのだが、これをきちんと語れるアプリケーションや業務処理の専門家は意外に少ないのである。

そもそも弊社がなぜこの仕組みを提供することになったかといえば、統合化部品表のTotalBOMと生産管理のQuickCIMはパッケージとしては別商品として販売されているが、データベースとしては共通(というのは、設計から生産は連続的な流れだからです)であるし、双方のプログラム(サービス)が同時に必要な業務パターンがいくつも存在するからである。
その時に不必要なプログラムも含めて購入する必要はないし、その組み合わせもユーザーのニーズ毎に変化するのである。
これをカバーするために、今回のECObjectsはプログラムのあり方を全面的に見直し、1つ1つのプログラムが独立したサービスとして活用できるように設計されているのである。

弊社では今後、従来型のパッケージとしてのECObjectsの販売と並行して、このビジネスプロセスSOA型のサービスの販売も行う予定である。もちろん、SOAであるから、WebからSaaSのようなサービスとして使用することも可能とする予定である。
まずは、設計から生産までの様々な業務パターンを用意したので、その業務パターンに応じて必要なサービスを自由自在に組み合わせて購入できるモデルを今回発表することになった。

ソリューションもフレンチのアラカルトのメニューのようにお客様のニーズに合わせて自由に組み合わせて使える時代が登場したのである。
ビジネスプロセスSOAに関しては弊社ホームページにも近々業務パターンを発表する予定である。乞ご期待。