システム構築の実践から学ぶSOAの基礎と本当のメリット
|
SOAの実践
ここからは、具体的なビジネスシーンを想定して、システム構築にSOAを適用する例を解説しよう。
適用シナリオ
今回は、例として卸売業の物流システムを取り上げることにする。大手卸売業のX社は、ここ数年、企業規模拡大のためのシステム統合を繰り返してきた。そのため、X社の物流センターはそれぞれが独自のシステム構成になっている（図2）。本部システムと各物流システムとの連携はX社の社内ネットワークを通じて行なっているが、日次バッチでの連携なので、本部への反映は一日遅れである。
ここで、「各物流センターの欠品対応の業務を効率化したい」という要求が高まってきた。欠品対応とは、得意先からの発注に対する在庫がない場合に、ほかの物流センターから在庫の移動が可能かどうかを照会し、その結果を元に在庫を移動して欠品を解消する業務である。X社の欠品対応業務はシステム化されていないため、電話およびFAXによる照会を中心としている。
現状では、電話による照会に時間がかかり、各物流センターの情報を十分に集められないため、最適な在庫の移動ができないという問題がある。X社本部のシステム部はこの問題に対応するため、SOAを適用したリアルタイムの欠品対応サービスを開発することにした。
サービスの設計
サービスの設計は、トップダウンアプローチで行なうことにする。このフェーズでは
（1）業務分析、（2）サービス抽出、（3）メッセージモデリング、（4）WSDLの作成の順に行なう。
（1）業務分析
まず、システム化を行なう前に、現状の業務をどのように改善すべきかを検討する。現状の欠品対応業務の流れは以下のようになる（図3）。
1：欠品通知
物流センターAのシステムが欠品の発生を検出し、担当者に通知する。
2b～2d：在庫照会
担当者は近隣の物流センターB、C、Dに電話で在庫状況を照会する。
2b'～2d'：在庫照会（物流センター内）
各物流センターの担当者は在庫の照会依頼を受け、結果を回答する。物流センターB、Cは担当者が直接システムを操作して照会し、物流センターDではオペレータを通じて他社に委託している物流システムに対して照会を行なっている。
3：移動元決定
物流センターAの担当者は、回答結果を元にどの物流センターからいくつを自分の物流センターに向けて移動してもらうかを決定する。
4b～4d：移動指示
決定内容に従って、物流センターAの担当者が各物流センターにFAXで在庫の移動指示を送付する。
今回の例では、電話での照会やFAXでの指示を自動化することで業務効率を改善することを考える。そのために、現状業務フローを元にして必要な部分のサービス化を検討する。
（2）サービスの抽出
現状の業務を分解すると、大きく以下の要素からできていることが分かる。これがサービス化する業務の候補になる（図4）。
（1）欠品の通知を受け対応する
（2）在庫を照会する
（3）移動元を決定する
（4）在庫を移動する
これらのサービスについて、どこに配備されるべきかを考える。(2)(4)は物流センターで提供するべきものだ。(1)は各物流センターへの照会を同じ手順で実施できるところ、ということで本部に配置する。(3)も同様に本部に配置されるが、現時点では移動元の決定はまだ担当者の経験に頼っていて自動化できないため、各物流センターの担当者が処理を行なうサービスになる。
SOAの考え方によれば、サービスの提供元はコンピュータであることにはしばられない。サービスを提供する人は、ほかのサービスからの要求を受けて、意思決定の結果をシステムに返さなければいけないので、ここでは本部のシステムにWebアプリケーションを1つ作り、そのWebアプリケーションを通じて結果をシステムへ伝えることにする。