今日のつぶやき

Twilog

[Twitter]今日のつぶやき ff.im/cdkmX #

クラウド・デバイス」という用語はいいなぁ。定着しないかな。 #

クラウド・アプリケーションのモデルは、CIM、PIM、PSMのそれぞれが大きく変わる。
PSM(Platform Specific Model)はクラウド・プラットフォームが新しく導入されるので、大きく変わるのは自明。 @myen #

CIM(Computer Independent Model)は、クラウドの社会的な影響で大きく変わることが予想される。ソーシャル・メディア、ソーシャル・ネットワークを企業のビジネス・システムに取り込んでいくことになることは予想されるが、その先は分からない。 #

PIM(Platform Independent Model)への影響が当面の主題。画面設計+ER図だけでは通用しなくなる所までは確定しているので、新しい枠組みを確立しなければならない。 @myen #

クラウド・アプリケーションはリアクティブなサービス群を組み立てて並列・分散を実現することになる。これは、伝統的な逐次手続き実行モデルとは大きく異なる。現状のPIMは逐次手続き実行モデルを前提にカスタマイズされているので、ゼロベースで再構築が必要。 @myen #

リアクティブ・システムの記述には、オブジェクト・モデリングが向いている。逐次手続き実行モデルでのオブジェクト・モデリングは静的構造記述が主となるため、データ・モデリングとの差別化が事実上行えなかった。(ユースケース・モデルは本来的な意味では活用されていない。) #

リアクティブ・システムをオブジェクト・モデルで記述する肝は状態機械。オブジェクトが保持する状態の特定、オブジェクトが関与するイベントの特定、イベントの発生による状態遷移を愚直にモデル化することが基本となる。 @myen #

ただ、生状態機械はモデリングのビルディングブロックとしてはプリミティブなので、もう少し企業アプリケーション寄りの抽象を導入しないとPIM的には弱い。この有力候補なのがワークフロー。 @myen #

分散環境でのサービスの組み立てを支える技術はサービス・バスが有力。キューによる非同期処理、同報もサービス・バスで抽象化するとPIM的に扱いやすい。 @myen #

ワークフローには、フローチャートの側面と状態機械の側面がある。一般的には、フローチャート的な捉え方や実現方法が多いが、リアクティブ・システムの記述という目的では状態機械の側面が重要。状態機械のプロトコル・ドライバを記述するための抽象あるいはフレームワークとして利用したい。 #

クラウド・アプリケーションのPIMの構成要素として、2つの重要な抽象があることが分かる。ワーク・フローとサービス・バス。前者は状態機械のプロトコル・ドライバの抽象として。後者はサービス協調・組み立ての抽象として。 @myen #

サービス・バスとワークフローは、企業アプリケーション統合という、ある意味、特殊な分野の技術だったのだけれど、これがクラウドでは日用品として利用されることになる。 @myen #

サービス・バスとワークフローをAppFabricのブランドの下で、Windows... re: ff.im/cehMv #

これは、Amazonの戦略からも、IBMの戦略からも大ニュースかも。『Amazon Web Services Blog: IBM Tivoli Now Available on Amazon EC2ff.im/cf2fp #

Automatically shipped by LoudTwitter