Microsoft.NETのコンセプト

インサイドMicrosoft.NET(その1)

　ここで、Microsoft.NET以前(現在)を考えてみよう。

　何かアプリケーションやソリューションを構築する場合に、まずはベースとなるプラットフォームを考えなければならない。たとえば基幹システムを構築するのであれば、WindowsやUNIXなどがあるだろう。そして、その上でベースとなるオブジェクトの管理を行なうミドルウェアとして、COMやMTS、CORBAなどを意識しなければならないだろう。アプリケーションを開発するには、ユーザーインターフェイスを、データの受け渡しには、相手先のデバイスを強く意識しなければならない。そして、それらの条件を踏まえた上でコードを書かなければならない。この方式を採っている以上、自社がプラットフォームを持ち、かつインテグレーションも行なっているメーカーが強いということになる。

　ユーザー側から考えた場合、この方式では、ユーザーコードの作り込みが非常に多くなるとともに、プラットフォームの変更やデバイスを取り替える場合、ユーザーコードに変更を加えなければならないといった弊害がある。もちろんMicrosoftにしても、今まではWindowsプラットフォームの市場占有率を高め、その上のソリューションを増やし、そしてデバイスをディペンドするといった方向性を指向していたのは言うまでもない。ではMicrosoftは、Microsoft.NETで何をしようとしているだろうか。ここで、インターネットコマースサイトを構築する場合を例にして考えてみよう。

　コマースサイトの構築には、決済用の高額のアプリケーションを購入して、自社のシステムと連携させ、決済、認証まで行なうように作り込む必要がある。また、会員制であればユーザーデータベースを参照した認証も必要になるし、さらに物流面では、販売管理や在庫管理などのシステムを用意し、連携させる必要がある。

　問題となるのは、コマースサイトの本分からすると、最も重要なのは「コンテンツ」であって、コンテンツの準備と制作に多くのリソースを投入したいわけだ。しかし「決済」や「物流」といったサービスは、コマースサイトを構築しユーザーにサービスを提供する上で必要になる重要な部分であり、さらに、これらのサービスがすべてそろった大規模なコマースサイトを構築するには、莫大な資金と人的リソースが必要となる。

　ここで「サービス」の性質を考えてみると、「業界(業種)ごとに必要なサービス」「共通で使うサービス」といったように、利用形態によって共通で使われるサービスがあることに気がつく。Microsoft.NETでは、このような「共通で使うサービス」を、あらかじめMicrosoftやサードベンダーが用意し、アプリケーションサービスプロバイダがサービスとして提供しようというわけである。

Figure 1　Building BlockとWebサービスを使ったリアルなサービス

「業界(業種)ごとに必要なサービス」「共通で使うサービス」を使うという考え方を取り入れると、製造会社は「調達.COM」と契約して、インターネット上で公開している「資材管理」と「調達」サービスを自社のシステムから利用できるようにし、調達のリアルなサービスシステムを構築することができる。自社で「販売管理システム」を持つ販売管理会社が、インターネットを経由して「物流.COM」が公開している「在庫管理」と「配送管理」のサービスを利用する。この販売管理会社は、「在庫管理」と「配送管理」の両システムを、サービスとして「物流.COM」と契約してアウトソーシングし、さらに自社の「販売管理システム」とのシームレスな連携が取れるようになる。

　このサービスをMicrosoft.NETでは「Building Block」(Figure 1)と呼び、提供される複数のサービスを「SOAP」や「BizTalk Framework」を使って自社に合ったコードを追加し、まとめ上げるのが「.NETソリューション」というわけである。つまり、ほかの企業や組織が公開している「業界(業種)ごとに必要なサービス」や「共通で使うサービス」を組み合わせて、1つのソリューションとして構築し、自社ではコンテンツや企画の部分といった部分に注力することができるというわけである。

　すでにMicrosoftは、このBuilding Blockのサービスの1つとして、「Passport」という認証システムを提供している。コマースサイトは、Microsoftと契約することによって、自社で認証システムを用意するのではなく、Passportを利用できるようになる。また、この考え方に即して、提供される複数のサービスを組み合わせてソリューションを構築すると、バックエンドのサービスに変更が加わった場合でも、繋ぎの部分だけを作り変えればいいというメリットもある。これは、ビジネスの早い流れに対して追従できることを示しているだろう。

　この考え方は、Microsoft.NETのアークテクチャをまとめた「.NET Framework」に準拠したものだが、さらにMicrosoft.NETでは、ほかのプラットフォームとの間で、サービスの相互利用可能な方向性を示している。そして、構築されたソリューションを、携帯電話やPDAを始めとするさまざまなデバイスで使える仕組みも提供しようとしているのである。

　Microsoft.NETは、Microsoftにとって「諸刃の剣」となるのは間違いないだろう。Microsoftとしては、サービスを作るための開発ツールやインフラ、そしてバックエンドの製品群を提供することによって、勝ち残ると考えているようだが、果たしてMicrosoft.NETの本質は、これだけなのだろうか。