読者です 読者をやめる 読者になる 読者になる

そごうソフトウェア研究所

SOA、開発プロセス、ITアーキテクチャなどについて書いています。Twitterやってます@rsogo

サービス化のインプリをどこから始めるか

ここ最近のいくつかのプロジェクトを通して、機能・データのサービス化の実行を始める際に、その経緯に寄って、いくつかアーキテクチャ上の違いがありました。

その経緯なんですが、別に難しい話ではなくて、サービスを利用する側か、サービスを提供する側かどちらが切っ掛けになっているかというものです。

  • サービスを利用する側が必要なので既存アプリケーションにサービスを作成する場合

例としては、ユーザーインターフェイスを持つアプリを構築するプロジェクトで、ある画面で注文の履歴が見たいので、既存の注文受付システムにWebサービスのインターフェイスを用意して、それを呼び出すケースです。

  • サービスを提供する側が、この機能をサービスで提供すると決めて推進する場合

例としては、これまで注文実績データを周辺アプリに1時間おきに配信していた、アプリケーションがWebサービスの印アーフェイスを用意するので、既存の周辺アプリにリアルタイムで情報を取りに来いというケースです。


どちらのアプローチも課題としては、新規構築する側はいいのですが、既存のアプリケーションへの影響をどのようにコントロールするかにあるかと思います。
この理由はいくつかあります。

  • 既存アプリケーションの体制は運用保守体制であり、新しいサービス構築またはサービスを利用するためのスキルを持つ人が配置されていない
  • 既存の改修コストを誰が持つのか問題。既存アプリからすると、これまでのやり方で回っているのに、なぜこちらが費用と、人を出さないといけないのかという話になります
  • 既存のアプリケーションがWebサービスに対応できるようなプラットフォームではない可能性がある

それぞれのアプローチでどのような特徴があるでしょうか。

  • サービスを利用する側から切っ掛け

要件定義や画面設計を行っている途中で、あるデータが必要というのが明らかになるケースは多いですので、提供側の既存アプリケーションのサービス化のスケジュールがタイトになる場合があります。
Webサービス呼び出しにするのか、それはどこに配置するのか。または、既存のアプリケーションのDBに対してJDBCでつなぎに行くのかなどが技術的な検討テーマになります。

  • サービスを提供する側から切っ掛け

これまで配信していたデータの提供をやめるようなケースがありますから、既存のデータを利用していたアプリケーションに非常に影響があります。
そのため、利用者が多ければ、段階的な移行を含めて周到な準備が必要になります。
ただし、成功したあかつきには、運用コスト削減や、データや機能の集約といった効果が見込めます。