SOA の考え方 | |||
スペル | Service-Oriented Architecture | ||
出現時期 |
2004年頃 |
||
対象 | システム設計 | ||
主な関連用語 | SaaS | ||
内容 | |||
既存のシステム資産を『サービス』の単位で連携させ、企業の変化に対応できるシステム構築するための技術体系。 ここで云う『サービス』とは、業務の単位やプロセスを考えながら、ある程度意味のある大きさにアプリケーションを構成部品化 したものであり、外部から呼び出し可能なアプリケーションの機能である。 「問題の解決を目的とした既存技術の集大成がSOA」 |
|||
出現の背景 | |||
1. 企業の統廃合・事業再編・市場競争の激化といった内外の環境に対して、企業のシステム柔軟性が必要とされた。 2. 「変化し続け、複雑化するIT環境をどのように統合するか?」という課題に対応する解決策として浮上してきた。 |
|||
SOAの特徴 |
|||
1. アプリケーションが業務の処理単位で「サービス化」されている。
2. オープンで標準的なインターフェースでサービスが提供されている。 3. 外部から呼び出し可能なアプリケーションの機能である。 4. サービスの組み合わせにより必要なアプリケーションを構築する。 |
|||
SOAのメリット |
|||
1. 個々のアプリケーションを柔軟に組み合わせ可能で、プロセスの変更が容易かつ柔軟に行える。 2. システム自体も市場の変化に迅速に対応することが可能である。 3. 特定のインフラに依存していないため、ベンダーやプラットホーム選択の幅が大きい。 4. 各アプリケーションは他のシステムと「疎結合」であるため、システム開発が容易である。 5. サービス単位の構成要素粒度が大きいため、再利用性がしやすく開発の生産性向上が図れる。 |
|||
SOAの課題 | |||
1. 基幹系のシステムは高い信頼性が要求されるので、それを確保する仕組みが不可欠。 2. サービスを実行する際に、サービス同士を正しく連携させる仕組みが不可欠。 3. サービス間のやり取りを正しく進める機能が不可欠。 4. サービスを入れ替えた際の影響を分析する機能が不可欠。 5. マスター・データの整合性を図る仕組みが不可欠。 |
|||