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

この時間、東横線はいつも混んでるなぁ。ｲﾏｺｺ! L:神奈川県横浜市港北区大倉山１丁目１３−２０ #

Azureの調査も昨日で一段落。カバーしなければならない技術範囲が広くて大変だったけど、アプリケーション・アーキテクチャ案というところまで、思索を進めることができて収穫だった。 #

実際にアーキテクチャが機能するかどうかは、性能・品質・コストの要因が重要なので、検証待というところだけど、たたき台にはなるかな。 #

インフラからのボトムアップではサービス・バスが落とし所だと思うけど、アプリケーションからのトップダウンではもう少し抽象度の高い枠組みが必要。サービスを組み立てるための糊言語、実行するためのと処理系をサービス・バスの上に載せる。 #

サービスの糊言語としてはworkflowがひとつの切り口。AppEngineはこの切り口で進むのかな。ボク的にはApache Camel的なintegration frameworkのアプローチが面白いと思っている。いずれにしても、これからの分野。 #

workflowはcontrol flowの記述より、state、event、actionの対をビルディングブロックにした状態機械実行系、イベント駆動エンジンとして期待している。 #

serviceの糊言語としてはdata flow的な記述方式の方が記述能力が高そうな気がしている。integration frameworkに期待しているのはそのあたり。ただ、DSLはもっとチューンする余地がある。Scala DSLに期待。 #

今回Azureを調べるにあたって、AppEngineのプログラムを書いていて体験したこと、AppEngineのコミュニティから得られた情報が非常に役に立った。遅延、故障、非同期は実際に体験してみないと感触が分からない。 #

一方、AzureはMSの全方位戦略を反映して、ビジネスでクラウドを使う場合に考慮しなければならない論点が網羅されていてる。クラウドをビジネス向け技術、企業アプリケーション、といった切り口で俯瞰するのに非常に役に立った。 #

先端応用のプラットフォームとしてAppEngine。企業アプリケーションのプラットフォームとしてAzure。四捨五入するとそういう棲み分けになりそう。両方のプラットフォームをフォローしていくのがよい。 #

企業クラウド・アプリケーションで並列を扱う場合、PLINQ、DryadLINQがよいバランスの落とし所になっている。内部的にはF#とも共通する関数型メタ言語のエンジンを使っているらしいのだけど、SQL的な文法糖衣でアプリケーション・プログラマでも簡単に安全に利用できる。 #

関数型言語で企業アプリケーションを記述するのは少し無理があるので、並列処理の対象部分だけDSL的に抜き出して、C#のようなアプリケーション記述言語に埋め込むというアプローチが現実的。 #

12月4日にCamel 2.1.0リリース。Apache CamelでGAE用のコンポーネントが出てるやん。
camel.apache.org/gae.html #

AppFabricのService BusとBizTalkのESBの関係は未確認。AppFabricのService BusはMSMQとの連携はなさそうで、通信の中継に特化している感じなので、2つのBusが併存することになるのかな。 #

アプリケーション統合的な粒度のservice busと、もっと小さな粒度のservice busの二階建てにするのがよいか、ひとつにまとめた方がよいか、というのも論点。 #

ESBは重たいイメージがあるので、不揮発性キューを使わないライトウェイトな通信路よりのBusは存在意義があるかもしれない。クラウド・アプリケーションでは、粒度の小さいサービスをBusで繋ぎたいから。サービスのマッシュアップがクラウド・アプリケーションの特性。 #

Javaの本線はApache Camel/Apache Service Mix/Active MQ/CXFというようなスタックを考えている。この場合はESBをマッシュアップのBusとして使うことになる。 #

Apache Camel/Service Mix/ActiveMQ/CXFのスタックをappengineで動かすのは今のところ無理そう。今のところ、appengineのserviceは外部のbusにリーフとして接続されるようなアーキテクチャになるなぁ。 #

apache camelのscala dslはまだ開発中のフェーズみたい。期待して待とう。 #

ESBは事実上アプリケーション統合のための特定分野の技術だったけど、クラウド時代にはこの技術が通常のアプリケーションでも必須基盤となる、とみている。ただ、アプリケーション統合向けの重たい部分はそぎ落としたライトウェイトなものが必要になるかもしれない。 #

バス・アーキテクチャ上でのデータの共有は難しい問題。トランザクションへの考慮も必要になる。メッセージ交換のみでデータの共有を代替するのが理想。BASEを前提にすれば、案外可能かもしれないという期待がある。 #

クラウド時代に入ってサービスというビルディングブロックの価値がとても上がった。サービスを提供するためにはサーバを立ちあげないといけないけど、このコストが大きな障壁だった。 #

プログラムを固めたコンポーネント、さらにそれを固めたモジュールを物理ファイルとして配布するのがクラウド以前のベスト・プラクティス。プログラムの再利用方法としてサービスはニッチな手法だった。 #

クラウドによってサービスをビルディングブロックにする価値が飛躍的に向上。service busのニーズがそれに伴い向上する、ということかな。AppFabricのservie busをみてインプレッションを受けた理由を、改めて分析してみた。 #

component再利用時代はDI container、service再利用時代はservice bus。こう捉えてみたい。 @myen #

Amazon Web Services Blog: AWS Price Reductions and Free Inbound Data Transfer ff.im/cB8ey #

#appengine の30秒制約には、無限ループ・デッドロック・ライブロックによるCPUリソース、メモリリソース(VMリソース)のロックイン・浪費を防ぐ効用があるよね。無限ループバグでとんでもない費用請求されたら泣く。Azureはどう回避するのかな。 @myen #

Automatically shipped by LoudTwitter