SOA というか、Mule ESB を使って、こんな感じのサービスを、いろいろ開発している。
一番、多いのは、DB to DB のデータ転送サービス。
データベースにレコードを書きこんだら、その「書きこみイベント」を、サービスに通知する。
サービスは、その結果は、別のデータベースへの書きこみメッセージとして通知する。
(実装は、 Mule ESB の JDBC endpoint を使えば、メッセージの検知・消費・生成方法を簡単に宣言できる)
通知は、SMTP でメール発信でも良い。
CSV ファイル読み込みの場合は、 CSV ファイルを読み取り、一行ごとに、 JMS メッセージを生成(送信)する、という方法で実現している。
この、Mule ESB を使った、メッセージングスタイルのサービスを、どうやって、「分析・設計」するか、いろいろ考えていた。
で、ICONIX のロバストネス分析、そのまま、使える、という発想にたどりついた。
画面アプリ( Web アプリケーション ) は、MVC スタイル。
で、画面で、 submit ボタンを押す行為は、「メッセージの送信」ということ。
画面に、何か表示するのは、「メッセージの受信」ということ。
つまり、画面アプリも、メッセージングスタイルのアーキテクチャで考えればいいんじゃないかと。
そうすると、画面アプリも、ESBも、「サービスコンポーネント」に対するメッセージの送受信というモデルで、分析・設計できる。
私たちは、画面アプリの分析・設計は、ICONIX プロセスで、「ロバストネス分析」で、ずっとやってきた。
その方法が、そのまま、メッセージングスタイルのサービスにも、使えるのは、なかなか良い感じだと思っている。
アクターが「人」であれば、画面アプリ、アクターが、外部システムであれば、メッセージングスタイルのアプリ、というわけだ。
一番、多いのは、DB to DB のデータ転送サービス。
データベースにレコードを書きこんだら、その「書きこみイベント」を、サービスに通知する。
サービスは、その結果は、別のデータベースへの書きこみメッセージとして通知する。
(実装は、 Mule ESB の JDBC endpoint を使えば、メッセージの検知・消費・生成方法を簡単に宣言できる)
通知は、SMTP でメール発信でも良い。
CSV ファイル読み込みの場合は、 CSV ファイルを読み取り、一行ごとに、 JMS メッセージを生成(送信)する、という方法で実現している。
この、Mule ESB を使った、メッセージングスタイルのサービスを、どうやって、「分析・設計」するか、いろいろ考えていた。
で、ICONIX のロバストネス分析、そのまま、使える、という発想にたどりついた。
画面アプリ( Web アプリケーション ) は、MVC スタイル。
で、画面で、 submit ボタンを押す行為は、「メッセージの送信」ということ。
画面に、何か表示するのは、「メッセージの受信」ということ。
つまり、画面アプリも、メッセージングスタイルのアーキテクチャで考えればいいんじゃないかと。
そうすると、画面アプリも、ESBも、「サービスコンポーネント」に対するメッセージの送受信というモデルで、分析・設計できる。
私たちは、画面アプリの分析・設計は、ICONIX プロセスで、「ロバストネス分析」で、ずっとやってきた。
その方法が、そのまま、メッセージングスタイルのサービスにも、使えるのは、なかなか良い感じだと思っている。
アクターが「人」であれば、画面アプリ、アクターが、外部システムであれば、メッセージングスタイルのアプリ、というわけだ。