今日のつぶやき - goldenportのブログ

loudtwitterは何かの拍子でエラーが出ると止まるのか。活を入れたら復活したみたい。 #

それにしても、サービス部品をつないで処理を構築するのはエラーのハンドリングがややこしい。inter serviceのexception protocolみたいなのができないかな。 #

SOAは業務改善の方向に軸足があったこともあり、事実上アプリケーション統合のインフラという趣だった。サービスの粒度は大きく、大規模企業システムやB2Bが適用分野。 #

アプリケーション単体の開発でサービスをbuilding blockにする必然性もなかった。同一言語内でのコンポーネントレベルの疎結合度で十分で、開発も快適。 #

クラウドでは、サービスがbuilding blockになる。このため、大規模企業システムやB2Bで使われていたサービス構築技術が一般化するという流れも出てくる。SCA、WCFをこの視点で考えてみると面白い。 #

componentはclassを再利用、serviceはinstanceを再利用。クラウドはinstanceの再利用が行える点がcomponentとはニュアンスが異なる。機能の再利用に加えて資産の再利用、場の再利用が提供される。 #

サービス実装をWS-*やRESTにマッピングするホスティング環境&IDEはほとんど自動化できるはず。PIMではユースケースからサービス契約の抽出が本線。サービス契約から、WS-*, RESTマッピング、サービス実装の言語束縛Template生成までは自動化できそう。 #

SCA, WCFはちょっとしたサービスを作るのに使うのには重たい感じもあるけど、IDEでカバーしてくれるのであれば気軽に作れるようになるかもしれない。クラウド・プラットフォームのサービス・ホスティング環境でホストするにはSCA、WCF的な構成管理が合った方がよい。 #

ソフトウェア開発のスマイルカーブ。ソフトウェア開発の重点は、重量級のサービス部品と、UXを実現するためのマッシュアップに二極化する。サービス部品はものによるけど、ドメインをよく知っているプログラマの職人芸の世界になるとするとモデリングは要らない。 #

UXを実現するマッシュアップは、エンタープライズ・マイクロアプリケーションとシチズン・デベロッパーが一つの軸。ここもモデリングは要らない。 #

とはいえ、本格的なUXを実現するのは、本職の仕事なので、このあたりにモデリングを活用する場所がありそう。UXを汎用サービス＋カスタムサービス＋糊(ワークフロー，データフロー)で実現するメカニズムの構築はそれなりに大変。 #

クラウド・アプリケーションを考えるときに落してはならないのがメモリ資源の問題。揮発性、不揮発性ともどんどん大容量になるので、クラウド時代はメモリベースのシステムを前提に考えないといけない。 #

ドメイン・エンティティの全インスタンスをWorkerRoleのメモリに読み込んで動作するということが可能になる。N個のWorkerRoleでエンティティの世代管理をベースにした楽観ロックで動くようになると、従来的な意味でのDBとは別のアーキテクチャになる。 #

AppEngineはイベントハンドラモデルなので、デーモンプロセスを使ってNUMA的にメモリに常駐させる系のテクニックは使えないかな。 #

ドメイン・エンティティ・インスタンスのクラスタをクラスタ単位で退避・復元・同期(VMのページ処理)するための格納庫にはDKVSは十分すぎる機能を持ってる。ワンレベルストアもロストテクノロジ。 #

ほとんどの場合、全マスターデータはメモリに乗るかな。トランザクションデータはほとんどがappend-onlyやread-mostlyとすると、データ管理のバランスがずいぶん変わってくる。一度SQLから離れて考えてみた方がよい。 #

ログを出しながらメモリ上で動いていくイメージかな。ログが状態を記録に留める役割。色々なエージェントが出したログを後から立ち止まって検証するとその時の状況が分かる。歴史検証みたい。 #

動いている世界の中で自分が把握している情報を元に活動しログ(データ更新、状態遷移)を出力する(限定合理性)のだけど、結果として全体として矛盾しないログの出し方。そういう切り口の技術が求められる。これから色々と開発されるはず。一つのアプローチが冪等性。 #

昼にバーグでスタミナカレー(豚＆生卵)を食べたら、今晩の夜ごはんは豚カレーらしい。 #

Automatically shipped by LoudTwitter