« 値の変更が制限される項目「強属性」について | トップページ | マイクロサービスと基幹システムの本質 »

2015.12.14

マイクロサービスで周辺アプリと連係する

 暫定的に公開していた「花束問題」の実装版が完成した。最終的にテーブル37本、機能128本というコンパクトなシステムとして出来上がった。当初のRFPがどんなモデルに変化し、どのように実装されたのかを確認できる。統計処理や年次繰越まで含まれているので、ロット在庫管理をともなう通販業向け基幹システムの教材にもなるだろう。

 最後に仕上げた機能にWeb APIが含まれていたのだが、その実装作業が楽しかった。基幹システムにとってのWebサービス(マイクロサービス)の役割があらためて実感できたし、基幹システムの本来の役割についても考えさせられた。そのことをまとめておきたい。

 今回作り込んだWeb APIは以下の3つだ。これらが、http要求にしたがってDBを操作し、その結果をXMLやJSONに整形して返す。機能名から想像できるように、これらは「ECサイト構築のためのAPI」である。

・BF100 商品情報処理サービス
・CF200 顧客情報処理サービス
・CF210 注文情報処理サービス

 一般消費者を相手にする企業であればECサイトを擁していることが多いが、基幹システムとスマートに連係しているとは限らない。立派な基幹システムを持ちながら、テキストファイルを介して非同期に連係しているといったケースは少なくない(図1のA)。

▼図1.基幹システムとECサイトの連係パターン
20151214a

 上述したWEBサービス機能は、基幹システムと効果的に連係すると同時に、セキュアかつ保守性の高いECサイトを生み出すための道具立てだ。それを用いると図1のCのようになる(Bのほうが手っ取り早いように思えるかもしれないが、後述するようにそれは避けたほうがいい)。

 基幹システムが提供するWebサービスの役割は、ECサイトとの仲介に限らない。「取引先にEDI用Webサービスを提供する」の記事で説明したように、サーバ間連係(P2P)のためのAPIにもなる。また、営業活動用や実棚報告用といった社内用モバイルアプリを開発する際にも欠かせない。ようするにWebサービス機能は、多様なデバイスやサーバと基幹システムとを連係させるための基本コンポーネントなのである。

 この認識によって、基幹システムの本質も明確になる。基幹DBの中身は、基幹システムが一元的に保持する業務ロジックによって維持される。つまり、基幹システムの基本構成要素は、「基幹DB」と「業務ロジック」、そして、それらを基礎として用意される「制御アプリ」の3つである(次図)。

▼図2.基幹システムと周辺アプリの連係
20151214b

 「制御アプリ」のうち、システム外部に公開されているものがWebサービスである。EC用アプリ(ECサイト)等の周辺アプリは、基幹システムが提供するサービスを介してしか、基幹DBにアクセスできないように設計されなければいけない。つまり、図1のBのように、基幹DBに直接アクセスするようではいけないということだ。それを許せば、基幹側の業務ロジックと矛盾した形でDBが更新される事態を招き得るからだ。

 サービスを介してしか基幹DBにアクセスできないことは、周辺アプリにとっての制約ではなく「恵み」である。基幹DBとのやりとりがサービスに委譲されるゆえに、DB接続だのSQLだのトランザクションだのといったややこしい記述を抱えずに済むからだ。また、サービスを介すことで、同期/非同期の使い分けを含めた負荷分散の考慮もしやすくなるからだ。

 結果的に、アプリ開発の「気分」も違ってくるだろう。事業活動を支えるDBの整合性を維持するという役割を果たす基幹システムの仕様は、周到に文書化されつつ保守されなければいけない。いっぽう、周辺アプリについてはアジャイルにどんどん開発され、破棄されたらいい。企業向けアプリの開発者としては両方の気分を味わいたい。Webサービスを実装する過程で、そんなことにあらためて思い至った次第である。

|

« 値の変更が制限される項目「強属性」について | トップページ | マイクロサービスと基幹システムの本質 »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: マイクロサービスで周辺アプリと連係する:

« 値の変更が制限される項目「強属性」について | トップページ | マイクロサービスと基幹システムの本質 »