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

色々と考えてみるとRESTがクラウド・アプリケーションのアーキテクチャ上のキーポイント。当たり前といえば当たり前だけど再認識。迷ったらRESTにしておけば大きく外さない。 #

すべての機能をREST化することで、アプリケーション・アーキテクチャはシンプルにできる。AppEngine Javaは、そういう意味でかなり焦点を絞っているのがよいバランスとなっている。生Servletを見せている点、TaskQueue、Mailのハンドラなど。 #

service busはセキュリティや運用管理など色々な機能があるので、あまり単純化はできないけど、RESTだけでシステムを組むと割りきればservice busなしでカバーできる応用範囲は多い。 #

Azureも全体的な方向としてはRESTを指向しているようにみえる。AppFabric Service Bus、WCF(ADO.NET) Data Services、ODataなど。RESTベースにしておけば、AppEngineとAzureを適材適所で活用できる。 #

PSMのビルディングブロックをRESTサービスと簡明化すると、PIMでのモデリングのバランスも変わってくるかもしれない。RESTといってもステートレスの粗粒度のサービスの場合もあるし、状態を持ったエンティティの場合もある。PIMでどう見せるか。 #

クラウド・アプリケーションは非同期、イベント駆動が基本なので、状態の管理、リソース(エンティティ)&イベント＆状態→アクションによるディスパッチが重要になる。Azureの場合、AppFabric Workflowでどこまでできるかがポイント。 #

PIM段階でサービス(RESTサービスの抽象)、エンティティの状態機械を模型化して、AppFabric WFでの実装に落としこんだ後、追跡管理できるかというのも問題。粒度を揃えて1対1が維持できるようにしておかないといけない。 #

サービスと同じ抽象度のイベント、エンティティ、状態、アクションをすべてPIMとして模型化できるようになっていないといけない。イベント，エンティティ，状態＋ルールで発火するとするとルールの模型化も要りそう。 #

PIMを記述するための言語としては、UMLとテキストDSLが候補。いずれにしても、クラウド向けにカスタマイズが必要。UMLとテキストDSLの相互変換ができて、開発者の好みでどちらでも編集できるのが理想。 #

テキストDSLは、Java系だとScala、Groovy、JRuby。Azureだと"M"が候補。Visual Studioベースの開発では"M"+Microsoft.UML2ということになるのかな。 #

IDEの発達によって、EclipseやVisualStudioの中で相当の開発ができるようになっている。模型は、IDEによる開発のリズムを壊さないように、必要不可欠な抽象を補完するというような立ち位置がよい。 #

模型からコンポーネントなどをまとまった単位で生成する、実装から模型を再構築する、模型からテスト仕様、テスト・セットを生成する、というような関わり合いがよさそう。模型なんだけど実装と並行して協業がよい。 #

AppEngine、AzureのそれぞれでPIMと実装の間を埋める実現方法は色々と候補がありそう。PIMで模型化したサービスごとにAppEngine、Azureのどちらでも実現できて、RESTで相互接続、要件により載せ替え可能というのが理想形。 #

OO的に妥当で、AppEngineとAzureのどちらにも無理なく適用できる、ちょうどいい塩梅の抽象度を持った超模型(メタモデル)。基本的にはSimpleModelingの枠組みでいけそうな気はしているけど、どのあたりをカスタマイズすると良いのか思案のしどころ。 #

先日、要求開発が実用フェーズに入っているのを目の当たりにした。ビジネス・アジャイルとクラウドをつなぐハブとして使えるPIMというのも一つの目標。ライブ・プロトタイプや実装からのフィードバックという要素も考えていかないと。このあたりはIDEと統合されていないと難しそう。 #

JavaEE6も出たところで、JavaEE6, AppEngine, Windows Server, Windows Azureの混在環境(on-premise, cloud)を意識するのがよさそう。 #

JavaEE6ではJAX-RSに期待。Windows Server/AzureはAppFabricでRESTfulサービス。 #

Automatically shipped by LoudTwitter