サービス指向アーキテクチャ (SOA) へのテクノロジー非依存アプローチ: SOA の原点に戻る

作者 Sadek Drobi, 翻訳者 編集部 投稿日 2007年10月4日 午前3時6分

コミュニティ

SOA,

Architecture

トピック

設計,

Business Process Modeling,

エンタープライズアーキテクチャ

タグ

SOA Adoption,

ビジネスアーキテクチャ

サービス指向アーキテクチャ (SOA) は、エンタープライズソフトウェア開発の主流の 1 つとなりつつある。しかし、Dan North 氏によれば、SOA の採用をこれまで決定してきたのは、「SOA の複雑性を強調した上で、タイムリーに、利益になるソリューションを提供する」ことに関心を寄せるソフトウェアベンダである。結果として、多くの SOA アーキテクトが行う決定はテクノロジーに関する考慮事項に左右され、SOA という手法の真髄である、コアビジネスシナリオのマッピングとモデリングに焦点をあてることができていない。

この記事では、Dan North 氏が、SOA の設計を「テクノロジーに依存せずに」行う方法を説明する(PDF・英語)。サンプルとしては、「コンピュータや最新テクノロジーへの言及を排除する」ため、「1950 年代の企業」に存在したような休暇取得プロセスを使用する。このビジネスシナリオでは、従業員 Bob が、人事部の承認が必要な休暇を取得する。Dan North 氏が、ビジネスプロセスの綿密なマッピングに基づいて、SOA 要件を特定する方法を段階的に説明する。

SOA の用語では、人事部はサービスプロバイダです。そのサービスの 1 つが年次休暇の管理です。Bob はそのサービスのクライアントまたはカスタマとなります。休暇申請書にはサービスコントラクトを記述します。記入された申請書は非同期メッセージです。つ まり、Bob は、返答があるまで彼自身の作業を止めて待機することはありません。Bob は、通常の仕事を続けます。社内便がメッセージトランスポートとなります。この場合は、低信頼性トランスポートですが、Bob には、タイムアウトというエラー処理プロトコルがあります。カレンダーから 1 週間が過ぎたことを知ると、彼は人事部に電話をします。この電話は同期対話です。Bob はその時に電話口にいなければなりません。その後、メッセージを再送信するという方法でエラー修正を行います。

エラー修正方法の説明の中で、North 氏はビジネスプロセス モデリングによるSOA 要件の例をさらに挙げている。承認前に、休暇記録の休暇日数を減らす更新が行われ、その後この Bob の場合のように申請書が紛失してしまった場合、記録に不整合が生じる。このような状況を想定すると、「休暇取得サービスはトランザクション管理される必要がある」という要件が導かれる。申請は何らかの業務的理由で失敗する場合がある。たとえば、休暇を使い切ってしまっている、署名がない、などの理由が考え られる。SOA の用語では、これは「セマンティクス」または「ビジネスルール」と呼ばれる。この場合、当事者には失敗の理由を示す応答が送信される必要がある。同様に、 North 氏は、ビジネスコンテキストから、応答の相関関係、サービスの使用可能性、セキュリティまたはサービスの変化について SOA 要件を定義する方法を説明する。

North 氏は、実際のビジネスの問題に焦点を絞ることにより、「何を」と「どのように」を区別することが可能になると言う。

実は、真のサービス指向アーキテクチャには、ビジネスに直接的に対応するサービスしか存在しません。そうでなければ、ビジネスプロセスをモデリングしたことになりません。 「データサービス」や「レプリケーションサービス」などの抽象的な技術的概念は、ビジネスの観点からすれば何の意味もありません。(共通の技術的機能を提 供する共通モジュールやライブラリが存在する場合もあるでしょう。しかし、それらは実装するべきではありません。また、サービスとして扱うべきでもありま せん。)

同様の考えから、North 氏は、現実には 2 つの別々のドメインが存在する場合に、汎用の 1 つのドメインモデルを定義することは避ける方が良いと言う。たとえば、「休暇」は、Bob にとってと、人事部の休暇申請担当者にとってとでは意味が異なる。Bob は「ヤシの木」や「ビーチでの散歩」を連想しているかもしれないが、休暇申請担当者にとっては、「時間を管理するビジネスプロセス」である。North 氏は、このような 2 つのドメインは、それぞれそのようなものとして存在すべきだが、「休暇」は「各サービスに関連する細分化されたドメインモデルを総括する」 1 つのビジネス概念として使用される必要があると考えている。これは、現実を反映するという効果もあるが、アーキテクチャの観点からも利点がある。

サービスコントラクトは、休暇、派遣、または販売注文など企業レベルのビジネス概念の観点から表されます。ただし、サービスカスタマとサービスプロバイダは分離し、共通の言語でのコミュニケーションを可能にしながらも、それぞれ別個に変更できるようにします。

Dan North 氏は、ビジネスプロセスモデリングによる SOA の設計は、「完全に機能する SOA を実装するための最初の 1 ステップに過ぎない」ことを認めている。しかし、ビジネスに焦点をあてることにより、「テクノロジーの問題から離れて、サービスの意図を理解し、複雑なビ ジネスを調査する」ことができる。このようにすれば、SOA 要件は、テクノロジーの決定に制約されることなく定義される。そして、「その各要件は、モデリングの対象となったビジネスプロセスの観点において、識別可能なビジネス価値と必ず関連付いているようになる」。

原文はこちらです：http://www.infoq.com/news/2007/09/technology-agnostic-soa

• 次へ >