hmoriya .net style 森屋英治

一枚のアーキテクチャ図

企業にとって必要なアーキテクチャを検討すると、必ずどこの会社でも一枚のアーキテクチャ図を想像されます。古くは、クライアント・サーバモデル、物理三層モデル、論理三層モデルと言う言葉で連想されるアーキテクチャも、まさに一枚のアーキテクチャ図です。システム制約を整理していくと自ずとアーキテクチャ図が見えてきます。同じ制約の中で特定のソリューションを検討していくのですが、ここでアーキテクチャ図を書く方のバックヤードが大きく影響します。インフラよりの方、実装まで考慮してアーキテクチャを書く方、現行のシステムを踏まえてアーキテクチャ図を書く方など様々です。そうアーキテクチャ図は、書く方によって視点が違いますので、自然に俯瞰する図も変わるのが普通です。もちろん共通のモデリングツールを利用されていれば同じ視点の方で共通の表記のモデルが作成されてる例もあります。違って当たり前なのに、いつも同じアーキテクチャ図が異なる企業、異なるシステムで再利用されているは不思議でなりません。複数の視点によって書かれたアーキテクチャ図によって一つのシステムが表現されシステムがデザインされています。経験が豊富なアーキテクトの方は、アーキテクトを書いた後、あるいは書いている途中で不安に駆られます、「本当にこれで動作するのか、本当にこれでつながるのか、本当にこれで運用できるのか」。この不安を解消するためにアーキテクトの方は、小さな検証を繰り返します、まさにXPの用語でいうと「アーキテクチャスパイク」です。あなたの会社にいらっしゃるこの検証するかたを、私はアーキテクトと呼んでいます。俯瞰して、検証する、改善する作業ループこそが非常に重要です、眉間にしわを寄せている方が実は多いのも特徴です。IEEE1471を勉強されている方、ソフトウェアファクトリを勉強されている方は、異なるステークフォルダのViewpointを連想されると思いますが、まさに複数の視点でモデルを書くことが基本となります。ザックマンフレームワーク、マイクロソフトソリューションフレームワークもその一例です。

アーキテクチャの再利用と利用

ソフトウェア資産の再利用に関して相談されることが多いのですが、私はソフトウェアアーキテクチャによるソフトウェアの再利用をおすすめしていますし、すでに何社かの企業様に導入しています。アーキテクチャの再利用により、ソフトウェア資産を最大限再利用することを体系化し、実践してきています。最初に、アーキテクチャの再利用と利用は、その方向と考え方が全く異なることであることを説明しなくはなりません。再利用推進を前提としたクロスカットの組織は、必ず全社に適用するため汎化（一般化）したソリューションアーキテクチャ、またはフレームワークを構築しまが、多くの企業では、再利用まで至っていません。そうです、実際のプロジェクトへの適用がうまくいかないのです。この汎化と適用のバランスと方向が逆であることを理解していないために再利用できないのではないのかというのが、私の仮説です。適用するために汎化することを忘れ、汎化に集中するあまり実際に構築される方のことをあまり考えなくなり、適用率にこだわるあまり利用される箇所が限定されるのではないでしょうか。汎化には、範囲と度合いがあります、適用を前提として汎化するからこそ意味があるのです。ドメインに特化した汎化は、再利用率が上がるでしょうし、全社を前提とした汎化は、適用箇所が限定され効果が薄くなります。組織そのものも、汎化用と適用のチームは視点が異なりますので分けるのがよろしいのでないかと思います、実際、できる方は現場のプロジェクトに取り込まれてしまい、クロスカットの取り組みが維持できなくなります。汎化と適用の狭間には、非常に重要なバランスがあることを常に考えなくてはなりません。

ベータ１では、MVC1.0が含まれていません、残念。ベータ２で含まれる予定みたいです。

上記が、Webプロジェクトの一覧です。

2008の時は、DBからモデル生成しかなかったのです、実質DBからモデルを作成してからオブジェクトモデルを変更と行った流れでした。2010では、モデルからDBが生成できます。私が触っているのは、EDMツールで右クリックして、Generate Database Script from Modelを実行するとスクリプトを自動生成します。

すこし、Ruby On Railsを思い出しますね。

生成されるデータベースのテーブル名は、Entity名＋Setがデフォルトです。

少し触り出しました、第一印象として以外にWPF採用の割に動作が速く、デザインもかっこよくなっていることです。

モデリングも下記のようにUMLを含めて標準でサポートされていますし、レイヤ用のデザインも追加されています。

ワークアイテムなどの連携も標準でついているので、いよいよ連携が最初から考慮された統合ツールの進化が伺えます。

保証されているかわかりませんが、今のところVisual Studio 2008と同居させています。

Silverlightも２，３の選択が可能となっています、当たり前と思いますがありがたいと思いました。

「ロサンゼルス　１０月末の気候」

ロサンゼルスは、日によって日中３０度近くにもなり、夜は長袖が必要なくらいの気候です、ところが、アメリカのカンファレンス会場は大抵エアコンがすごく効いていますので、ジャケット、パーカーなどをお持ちなること御勧めします。アメリカの方は、半袖の方が多いのですが、日本人は、とても半袖で過ごすことができない寒さです。

「アーキテクチャから理解する」

いつもそうなのですが、初めて見るテクノロジーは、アーキテクチャから理解するようにしています、アーキテクチャの目的も俯瞰してものを見るため、あるいは、使う人に理解してもらうためにありますのでそのようにすべきと考えています。アプリケーションの場合、アーキテクチャは、コードの俯瞰であり、設計者の意図、制約が示されています。最近は、EA、ザックマンフレームワークにあるように様々な視点のアーキテクチャ存在しますが、私の場合ほとんどアプリケーションアーキテクチャを意味します。
それでは、Windows Azureのアーキテクチャについて説明していきたいと思います。前回、

Windows Azureの実態は、クラウド上にある冗長性を考慮した、WebRole( ASP.NET ) + WorkerRole + Storage (Table, BLOB, Queue )です、もちろん、Worker, Storage はオプションです。

と書きましたが、下にWindows Azureのアーキテクチャ図をPDCの　PPTから抜粋して説明します。

まず、フロントエンドは、ロードバランサーが複数のWebに振り分けていきます。WebRoleの部分は、厳密に言うと違うと思いますが、VSで開発される方には、下記のようにASP.NETのWebアプリケーションです。おそらく、別のアーキテクチャ資料から想像すると、この単位（WebRole, WokerRole, Storageの単位）で仮想サーバになっているようです。Web部分が中心的な存在になります、WebRoleからAccount情報を通して、Storageにアクセスします。

典型的なプロジェクト構成で作ったソリューションの画像を添付します。

WokerRoleは、COM+やサービスプログラム、ワーカースレッドとは似ているようですこし違うものなのですが、ようは常駐型、ワーカサービスです。現在のテンプレートもWhileループで、特定の情報、イベント、キューをチェックするような構成になっています。これも、冗長構成をとれますので、コンフィグだけでインスタンスの数を指定できます。キューや、ストレージへのアクセスは、Webと同じように、Account情報を元にして行います。GetHealthStatus()の戻りが、Healthyっていうのはすこしオシャレですね。

いい言い方をすれば、すでにエンタープライズで適用できるアーキテクチャフレームワークが提供されています、この点がWindows AzureがPAASであることを示しています。AmazonのEC2は、サーバそのものを提供しているので、HAASと呼べると思います。ASP.NETという開発はそのまま使えるのですが、100％そのまま現行のWebアプリケーションをクラウドへというものではなく、Windows Azureのアーキテクチャに従って構築する必要がある部分があることを注意しなくてはいけません。リリースされる頃にはこの点はもっと解消されているかもしれません、サービス思考で作られている方のほうが移行は簡単になることは間違いないです。

1. PDCを終えて　その１
2. PDCを終えて　その２ Windows Azure登場
3. PDCを終えて　その３ Windows Azure　アーキテクチャ

その１では、PDC2005について少し触れていきました。いよいよPDCの話に入ります。
久しぶりのPDCで興奮しながら前日にロサンゼルスへ到着しました、前夜はマイクロソフト株式会社主催の日本人パーティーがあり、お誘いいただきました。いつものメンバーというとそれまでですが、日本を代表するマイクロソフト関連の方々が集まっていました。皆さん明日何が出るか非常に興味深い様子で、前日なので言いたくてもあまり答えられないマイクロソフトの方がすこしかわいそうでした。
前置きが長過ぎるので、初日の話に入ります、ビルゲイツがいなくなり最初のPDCで心配していましたが、Ray Ozzie氏がアーキテクトとして最初に登場しました。会場はかなり盛り上がり、いよいよ最初の製品発表”Windows Azure”の発表です。
http://channel9.msdn.com/pdc2008/KYN01/
セッションはかなりあるのですが、キーノートはぜひビデオを視聴されることを御勧めします。

Azureはフランス語らいしので、発音は難しいのですが、”アジュー”、”アジュール”。。。正式にはわかりませんが、意味的には、クラウドを包み込む青空をイメージしました。
クラウドコンピューティングというと amazon, googleをイメージしていましたが、いよいよマイクロソフトも Windows Azureを中心したクラウドサービスを提供するとの発表でした。

Windows Azureの実態は、クラウド上にある冗長性を考慮した、Web( ASP.NET ) + Worker + Storage (Table, BLOB, Queue )です、もちろん、Worker, Storage はオプションです。
開発は、Visual Studio 2008 SP1 on  ( Windows Vista or Windows Server 2008 )で、IISは必須の状態で、ローカルでの開発後、パッケージを作成し、クラウドへ展開するものです。ローカルでは疑似環境が提供され、Webのホスト環境（Fabric）とストレージの疑似環境を提供しています。
これまでと同じように.NET Frameworkで、これまでと同じようにASP.NETで開発できるのが、マイクロソフトの提供するクラウドコンピューティング Windows Azureです。私が、前日に勝手に想像していたよりずっとエンタープライズ、および商用を考慮した冗長性も考慮したものでした。私が想像していたものは、コンシューマよりのこれまでのLiveサービスが提供している範囲と考えていました。

実は、マイクロソフトのストレージは２つ存在します、一つはこのWindows Azure Storage, もうひつは、 SQL Data Serviceです。最初は、なぜ２つ存在するのか疑問でしたが、生い立ちを考えるとうなずけます。もともとマイクロソフトは、SQL Server Data Serviceを開発して、ベータ版を提供していました、Windows Azureには、WebとWorkerをつなぐなめ（冗長構成のため）、Queue構造が必要でした。最近では、Queue構造にデータベースを利用するのは、バックアップも含めて有力なデザインのひとつです。

参考：

マイクロソフト PDC 2008 http://microsoftpdc.com　A Lap around the Azure Services Platform より出展

最近、Windows Liveの傾向を見ているとデスクトップアプリケーションとLiveサービスの融合がたくさん見られる。たとえば、Windows Live Mailですが、完全にデスクトップアプリケーションとして動作するし、サービスとしてはネット上のLive Mailを利用している。もちろん、モバイルでも閲覧可能だ。Web 2.0のおかげでサービスとしての充実が進んでいるが、現実解としてのデスクトップにもう一度気が付いてきたかたちに見える。実際、画像の添付、履歴操作性の観点でも私もLive Writerを利用している（５０％くらい）。

もともとGoogleは、サービスと画像処理ソフトなどデスクトップの利用を併用して考えられていたが、Web2.0の部分がもてはやされそれに従った企業が急激に増加してきた。いい意味で、Webの可能性が広がった、デスクトップアプリでは簡単に作れる内容でも、Ajax系のアプリケーションでは非常に大変で、サポートするブラウザが増えれば増えるほどテストが増大する。パブリックなサービスであれば、すべて、つまりWeb、デスクトップ、サービス、モバイルなどの提供レベルが上位のものを目指すべきで、当然利用者の利便性、満足度は向上する。一方で、作成コストは増大し、テストコストも増大する。ゆえに、サービスを共通化し、フロントエンド（Web,Desktop,Mobile)の特徴を”生かすソフトウェア”が重要になってくる。ここで、注意しなくてはならないのは、本当に必要かだ。このようにサービスレベルを上げていくと、公共性が高いアプリケーションではいいが、特定の対象、スコープがあるアプリケーションでは、そのコストに全く見合わない。もちろん、これは、ハードウェアにも言えることで、ターゲットユーザ、提供サービス、コストのバランスが重要といえる。

いい意味で起こったWeb2.0ブーム、その波を利用して、もう一度Software + Serviceや自分の対象アプリケーション、対象顧客を見直して適切な構造のアプリケーションを再考する次期なのかもしれません。波に乗り遅れた方は、はじめから後者を考慮していくべきすね。