2012 06
20
  • このエントリーをはてなブックマークに追加

サービス指向アーキテクチャとは

カテゴリ:アーキテクチャ タグ : ,

やぁ、皆さんお久しぶりです。えなみんです。
またもや一ヶ月ぐらい放置してしまうところでした。
如何せん通勤に時間かかると、家でゆっくり出来る時間が少なくてあれでこれで……(ゴニョゴニョ
まぁ、全部言い訳なんですけど。書く時間はたっぷりございました(キリッ

さて、今日はちょっとばかし、私が携わっている業務についてお話しますよ。

「人のやってる仕事の詳細聞いて何がおもろいねん」

と仰る方はご尤も。
正直面白みには欠けると思いますが、概念的なお話なので少しは面白いんではないかと。
今日話すのは

「サービス指向アーキテクチャ」

俗にSOAと呼ばれているものです。


概説はWikipediaさんが詳しいです。

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

引用:Wikipedia


となっております。
まぁ、これだけ見たところでさっぱりだと思いますので、軽く説明します。
Wikiを詳しく見るとこちらも書いてあるのですが

良く聞くオブジェクト指向とは全く考え方が異なっているものです。
あくまでオブジェクト指向というものが、プログラムの粒度を主軸にした開発概念であったのに対して、サービス指向はサービスという一つの処理を一単位として捉えています。

開発者としてはプログラムのオブジェクトを一単位として捉えた方が、はっきり言って開発は行いやすいです。
しかし、現実には迅速に変化するIT情勢を踏まえた上で、そのスピード感に合わせ企業もシステムを更新していかねばなりません。
こうなってくると変化に対応するだけで、途轍もないリソースやコストが必要となり、何のためにシステムを運用しているのかが不明瞭になってしまいます。

その為にサービスという一つの処理に対して、一つのプログラムという形を取っていく必要性が生まれたのです。
例えば「決済処理」というサービスを、必要に応じて他のサービスが利用します。
一つのサービスの中に「決済処理」が入っているわけですから、他のサービスは利用したいサービスを呼び出すだけでその処理を行う事が可能になります。
ここらへんはオブジェクト指向と似ていますが、粒度が違う為に変更を加えるのが、著しく容易になります。

また連携を基本概念として置いている為、特定のソフトウェアや規格になるべく依存しないよう設計します。
その為、オープンソースの組み合わせを含めた様々なソフトウェアを利用する事で、より柔軟な開発をも可能とします。
勿論上述されているようにネットワークを用いますので、利用するサービスというものは殆どがWebサービスです。

これもWikiに書いてるよ!!
SOAはWebサービスを主軸に置いて利用する事が前提となっています。
実際にはそういうわけではないのですが、こちらについては割愛します。

さて、ではまず基本的なとこから。

SOAP

SOAP(ソープ)は、ソフトウェア同士がメッセージ(オブジェクト)を交換する(リモートプロシージャコール – 遠隔手続呼び出し)ためのプロトコル。
引用:Wikipedia


SimpleObjectAccessProtocolなんて呼ばれていた事もありました。
今はソープと呼び、特に何かの略語ではありません。
ただ、以前の名の通り実にシンプルなメッセージ交換、サービス応答を行います。
こいつがないとそもそもサービス呼び出しすら行えないので、連携が出来ません。
現在の最新バージョンは1.2。

WSDL

Web Services Description Language (WSDL) とは、Webサービス記述言語、またはそれによって記述された定義ファイルの総称。XML形式で表記される。
Webサービスの具体的内容を記述するもので、サービスの提供されている場所、サービスに用いられているメッセージのフォーマット、プロトコルなどが記述される。
引用:Wikipedia


これについてはWikiさんのまんま。
最近では、ApacheCXFを使った自動生成が主流ではないかと。
CXFを使うとサービスのインターフェースからWSDLを自動生成してくれるので、手間隙省けます。

ESB

エンタープライズ・サービス・バス(英: Enterprise service bus, ESB)は、一般に標準に基づくミドルウェアインフラストラクチャー製品で実装されるソフトウェアアーキテクチャの構成要素であり、上位のより複雑なアーキテクチャの基盤となるサービスを提供するイベント駆動型で標準ベースのメッセージングエンジン(バス)である。
引用:Wikipedia


何語?
簡単に言うとサービス間を繋ぐハブみたいなもの。中継器。
サービスからサービスっていう一対一の通信を行うよりも、間に中継器を入れておくことでそのサービスの通信を監視することが出来るってわけですな。
監視といっても、実際の役回りとしては受け取った通信プロトコルの変換や、通信内容をキャッチして、別処理を行わせる、とか。
単純な通信に色々と機能を追加する類のもの。
今はESB Muleと呼ばれるコンポーネント集みたいなのを使ってます。
こっちは単純なESBとは違うので、また後日。


などなど。
これらがある為にSOAはWebサービスを前提としているところが多いわけです。
SOAPとWSDLだけでなく、他の技術的要素がやっぱりとても便利で、環境が揃っているんですよね。
2004年という結構最近から流行り始めたとあるけど、理由としては色々と問題があったから。
ネットワークを介したサービス連携っていうのは、色々な問題を抱えとるわけです。これに関しては現在も進行中。マシになっただけです。
後、2004年っていうのはあくまで海外の話。
日本国内では2010年ぐらいから大手が参入してきたぐらいで、今だ成功事例は少ない状態。

SOAはスピーディに変化に対応できて、ネットワークを介したサービス連携によってシステム間の統一がやりやすいので、基幹系再構築の際に良く取り入れられます。
しかし、実際には導入にとんでもないコストがかかるというネックがある。
コスト削減になるとされているSOAだが、それはあくまでランニングの話であって構築段階ではとんでもないコストがかかってしまう。
しかも構築段階でSOAが機能していなかったりするとランニングのコストも変わらなくなってしまって、散々な結果になる。
ここは良く勘違いの起きやすい部分。

っとまぁ、ざっくりSOAについて解説しましたが、ご理解いただけましたでしょうか。
正直私も全部が全部を理解しているわけではないので、間違いも多いかもしれません。
間違っている部分に気付いたらご指摘を頂けると助かります。

以上、久々のブログはこんな感じで!
自分の勉強がてら、こういう記事をいくつかアップしていく所存にございますので、よろしくお願いしますー。

関連記事

コメントはこちらから




?
© 2017 Peace & Piece. All rights reserved.