アットマーク・アイティ @IT@IT情報マネジメント@IT自分戦略研究所QA@ITイベントカレンダー  
 
 @IT > .NETプラットフォームが選ばれた6つのテクニカル・アドバンテージ<前編>
 
@IT[FYI]

 

.NETプラットフォームが選ばれた
6つのテクニカル・アドバンテージ <前編>


  .NETとJ2EE、サーバサイド・テクノロジの真実

 企業システムにおけるWebアプリケーションおよびWebサービスのプラットフォームは2005年現在、ほぼ2つのアーキテクチャに収束したといえるだろう。まずWebアプリケーションのアーキテクチャとして支持を集めたのはIBM社の WebSphereやBEAシステムズ社のWebLogicといった製品で実現されるJ2EEであり、続いてマイクロソフトの提供する.NETが急速に追い上げている。

 新規のシステム開発を決定した企業は、それがWebアプリケーションであるかぎり、.NETあるいはJ2EEのどちらのアーキテクチャを採用するか、難しい判断に迫られる。テクノロジの差異というより、選択したプラットフォームの差異による生産性、信頼性、パフォーマンス、管理容易性、コスト(初期導入や運用)など多くの要因を総合的に考慮しなければならず、単純に.NETとJ2EEの優劣を決められるわけではないが、本記事では両陣営の提供するテクノロジを個別に検討していくことで、プラットフォーム選択に参考となる情報を提供していく。

 前編では、サーバサイドのコアテクノロジとして、「Webアプリケーション・サーバの技術基盤」「ビジネス統合ミドルウェア」「統合開発環境」の3点を考察してみたい。

   


Webアプリケーション・サーバの技術基盤

 現在のWebアプリケーションはECサイトやインターネットバンキングなど、非常に高機能で高負荷に耐えられるものになっているが、インターネットが普及した当初はPerlやPHPといったスクリプト言語で記述されたCGIプログラムをWebサーバから呼び出すシンプルなアプリケーションだった。

 ところが企業が本格的にWebアプリケーションによる業務システムを構築するようになると、CGIプログラムの欠点が露呈したのである。それは

  • スケーラビリティの不足
  • 高可用性の不足
  • 開発生産性の低さ

の3点に集約されるといえよう。この短所を乗り超えるために登場したのが「分散型コンポーネント」と呼ばれる新しいテクノロジだった。複数のサーバで構成されるクラスタリング・システムの導入でスケーラビリティと高可用性を実現するには、アプリケーションの部品をコンポーネントという単位で独立させ、サーバの負荷に応じて処理を振り分ける、あるいは障害の発生したサーバでの処理を別のサーバへ振り替えるといった、分散型のアーキテクチャが必須となったのである。また、開発の規模が拡大するに従い、大規模なチーム開発が当たり前となると、アプリケーションを部品単位でコーディングする開発手法が求められた。

(1)Webアプリケーション・サーバ

 現在のWebアプリケーションは.NETでもJ2EEであっても、基本的なアプリケーション構成は共通している。つまり、Webサーバ経由でユーザーからのリクエスト/レスポンスを処理する「プレゼンテーション層」、バックエンドでデータを格納する「データベース層」、これらの中間でビジネス要件を満たす処理を行う「ビジネスロジック層」といった3階層構成である。

 データベース層は以前からデータベース・サーバとして独立していたが、Webアプリケーションで問題となったのは、プレゼンテーション層とビジネスロジック層をいかに独立させて、開発生産性とメンテナンス性、高可用性を向上させるかであった。

 3階層構成の実現のために.NETとJ2EEで用意されている要素技術を見ていこう。J2EEでは「Javaサーブレット/JSP」がプレゼンテーション層を担い、ビジネスロジック層は「EJB」を用いる。ユーザーからのリクエストを受け取るのはJavaサーブレットで、リクエストの内容に相応するEJBを呼び出して処理を委譲する。EJBは必要に応じてバックエンドのデータベースと連携して、ビジネスロジックを実行し、その結果はJSPによってユーザー画面に表示されるという流れだ。このようなモデルを「MVC」(Model View Controller)と呼ぶ。

 ここで重要なのは分散型コンポーネントのEJBである。EJBはサーバの負荷に応じて、クラスタリング構成中で負荷の少ないノードに振り分けられるが、アプリケーション開発者は負荷分散のロジックを一切気にする必要はない。負荷分散を管理するのはJ2EEサーバ(アプリケーションサーバ)と呼ばれるJ2EEコンテナの役割である。

図1 J2EEの3階層構成
J2EEサーバ製品にはWebサーバも含まれることは多いが、一般的に運用時にはよりパフォーマンスの高いApacheなどを利用してWebサーバを独立させる構成が取られる。EJBには、セッション状態を維持しない「Stateless Session Bean」、セッション状態を維持する「Stateful Session Bean」、そしてデータベース接続によるデータの永続性を保証する「Entity Bean」がある。

 J2EEアーキテクチャを整理すると、OS上のJ2EEサーバがコンテナとして負荷分散、セッション管理、データベース接続、分散トランザクション、セキュリティといったインフラ機能を提供し、その上にユーザー・アプリケーションであるコンポーネントを配置するという「コンテナ・コンポーネント・モデル」で、OSとJ2EE対応Webアプリケーション・サーバは互いに独立している。J2EEサーバの代表的な製品にはIBM社製の「WebSphere」、BEA社製の「WebLogic」などが挙げられる。

 一方、.NETの3階層構成はプレゼンテーション層に「ASP.NET」、ビジネスロジック層が「Enterprise Services(COM+)」となる。

図2 .NET Frameworkの3階層構成
.NETではWindows Server OSに.NET FrameworkおよびIISやEnterprise Servicesなどのアプリケーション・サーバ機能が一体となって提供されている。また、データベースサーバにSQL Serverを採用すれば、システム全体をWindow Serverアーキテクチャで統一し、すべての開発をVisual Studio .NETで行うことが可能になる。

 .NETの技術情報の詳細は、MSDNの技術文書「小規模から大規模システムまでをカバーするマイクロソフトのアプリケーション フレームワーク」の該当個所を以下より参照していただきたい。

 ここで押さえておきたいのは、.NETとJ2EEの分散型コンポーネントは、プレゼンテーション層においてASP.NETとJavaサーブレット/JSP、ビジネスロジック層においてEnterprise ServicesとEJB、データベース接続ではADO.NETとJDBCがそれぞれ同等の機能を提供している点だ。仕様上に多少の差異は認められるにせよ、どちらのアーキテクチャも同じような思想に立脚しているといってよいだろう。

  .NET J2EE
プレゼンテーション層 ASP.NET Javaサーブレット/JSP
ビジネスロジック層 Enterprise Services(COM+) EJB(Session Bean)
データベース接続 ADO.NET JDBC/
EJB(Entity Bean)
表 .NETとJ2EEの3階層構成の要素技術比較
データベース接続では、ADO.NETはJDBCないしBMP Entity Beanに相当する。

 では、プラットフォーム選定で問題となるのはどの部分だろうか。両陣営の決定的な違いは、J2EEではOS+J2EEサーバ+コンポーネントの3重構造だったものが、.NETではOS+コンポーネントの2重構造に統合されていることだろう(上述の図1、図2を参照)。Windows ServerはOSであると同時に、WebサーバのIISを内包し、負荷分散、セッション管理、データベース接続、分散トランザクション、セキュリティといったインフラ機能を提供する.NET FrameworkがWindows Server自体に組み込まれ、さらにコンポーネントの実行環境ともなっている。

 この.NETのシンプルな構成は、後述する開発生産性や導入・環境構築の容易さ、サポート体制の一貫性など、さまざまなメリットを提供してくれる。一方で、.NETはプラットフォームがWindows OSに限定される制約が生じてくる。J2EEのマルチプラットフォームを取るか、.NETのシンプルさを取るかが選定のポイントとなるが、その判断は後述の諸要素も含めて、総合的に判断すべきだろう。

(2)開発言語

 Webアプリケーションの開発がCGIから.NET/J2EEに移行した背景には、増大する機能要求に対して、PerlやPHPなどのスクリプト言語では対応しきれなかったからである。本格的なオブジェクト指向言語による開発が必須となった。

 日本でも2002年前後から急速にUMLを使ったオブジェクト指向開発の導入が進んだ。その当時、オブジェクト指向言語として普及していたのはJavaであったため、UML=Javaといったイメージが先行したが、本来UMLは実装言語に依存しない抽象的な設計ツールである。UMLで標準化されたダイアグラムを使ってオブジェクト指向的にシステムの設計を行うことは、高機能化に対応して多数のプログラマを投入するWebアプリケーション開発に、非常に有効であると認識されるようになった。

 それまでVisual BasicやVisual C++が中心だったWindowsアプリケーションの開発環境にも、2002年にリリースされたVisual Studio .NETから新たなオブジェクト指向言語として「C#」が導入された。C#技術情報の詳細はMSDNのWebページに掲載されている以下の技術文書を参照していただきたい。

 ・Microsoft Visual C# 技術資料

 言語仕様を比較すると、後発であるC#はJavaのオブジェクト指向言語の良い部分を取り入れたうえに、属性の指定やビジュアル開発環境との連携といった実用性において、よりプログラミングを効率化する仕様を取り入れている。また実行効率の面では、マルチプラットフォーム対応のJavaに比べ、単一プラットフォームに特化したC#は、システム全体のパフォーマンスにおいて有利である。

 .NETはマルチ言語に対応しさまざまなデバイスに搭載可能であるが、プラットフォームはWindowsファミリーのみとなる。一方、Javaは基本的に単一のJava言語のみでマルチプラットフォームに対応する。例えば、サーバサイドの旧COBOL資産の移行性など、既存の開発リソース(既存のソースコード資産、開発者のスキルなど)の有効利用を考慮すると、単一の言語での開発を強要するよりも、.NETを選択しプロジェクトに合った言語を自由に選択するといった判断もあり得る。Windowsファミリー以外のプラットフォームを視野に入れるなら、Javaを選択することになるだろう。

(3)フレームワーク

 CGIからオブジェクト指向開発、分散型コンポーネント・モデルへと進化したWebアプリケーション開発は、新たな困難に直面した。開発要件が高度になるにつれ、スキルの伴った開発者の不足が表面化したのである。これは特にJ2EE開発で顕著となった。J2EEの開発者は、前述のServlet、JSP、EJBのほかにもJNDI、JDBC、RMI、Java Beanなど非常に多くのAPIを理解し、なおかつJ2EEアーキテクチャに基づいた開発モデルを実践する必要があり、技術の習得が追い付かない状態が続いた。

 これに対して.NETは、エンタープライズシステムに求められる諸要素をあらかじめ設計思想として組み込んだフレームワークを当初から用意している。これは.NET Frameworkと呼ばれるもので、Webアプリケーションに必要とされる以下の機能をビジュアル開発環境とともに提供しているのだ。

  • ASP.NET(Webアプリケーション開発・実行基盤)
  • ADO.NET(データベースアクセス支援)
  • Enterprise Services(COM+)(分散型コンポーネント支援)
  • CLR(ランタイム環境)
  • クラスライブラリ、ドキュメント(開発支援)
  • Visual Studio .NET(開発ツール)

 .NET Frameworkの詳細については、MSDNの技術文書「小規模から大規模システムまでをカバーするマイクロソフトのアプリケーション フレームワーク」の該当個所を以下より参照していただきたい。

 .NET Frameworkでは、後述するシステム連携を実現するためのWebサービスの実装方法が組み込まれていたり、ブラウザベース・アプリケーション以外のインターフェイス(Windowsアプリケーション、Officeアプリケーション、PDA)もサポートしているなど、常に一貫性のあるビジュアル開発環境を利用できる。

 開発者は複雑なコーディングを必要とせず、代わりに必要な機能をモジュールとして呼び出すだけでよく、開発案件に固有のビジネスロジックに専念すればよい。ここは、単一ベンダがOSからフレームワーク、Webアプリケーション実行環境、開発ツールまでを一貫して提供しているメリットといえよう。

 J2EE陣営でも、フレームワークを使った開発生産性の向上を目指し、J2EEフレームワークを採用する動きが強まった。現在、WebSphereなど代表的なJ2EEサーバ製品は「Struts」と呼ばれるオープンソースのJ2EEフレームワークをベースとし、各社が拡張機能を追加した開発環境をリリースしている。J2EEにはほかにも「JSF」や国内のシステム開発会社が独自に作成したさまざまなフレームワークを利用できるが、選択肢が多いことでかえって複雑度が増し、開発コストの増大につながる危険もある。また、独自のフレームワーク拡張がブラックボックス化し、担当したシステム開発会社以外ではメンテナンスが困難であったり、各種のStrutsマイナー拡張がシステム開発会社ごとに存在することで、資産の流用性が損なわれることもある。

 ここで.NET FrameworkとStruts系のフレームワークの特徴をまとめておこう。.NET FrameworkではOSであるWindows Serverとフレームワークが完全に統合された同一製品として提供されており、よりシンプルで開発者の負荷を低減させる点が注目される。これに対し、J2EEは当初、個別のAPIが順次リリースされ、その後フレームワークの導入に至った経緯がある。J2EEはある程度開発生産を犠牲にして開発の自由度を追求してきたといえるだろう。複雑で難易度は高いが、その分だけアプリケーション設計の自由度は高いと考えられる。

   


ビジネス統合ミドルウェアの充実度

 Webアプリケーションの性能と信頼性が大幅に上がったことで、企業システム開発において新たな要求が持ち上がっている。それは以前から求められながらも、なかなか達成できない企業内のシステム統合だ。企業のITシステム投資はここ数年めざましいものがあったが、それは部門や営業/製造拠点など、部分最適化を目指したシステム化であった。その結果、企業内に数多くのシステムが孤島のように乱立し、しかも各システムのプラットフォームはレガシーからUNIX、Linux、Windowsとばらばらだ。これらを統合してシステムの全体最適化を図りたいという要求が強まってくるのは当然な流れである。

 Webサービスを実装したWebアプリケーションは、従来のEAI製品に取って代わるシステム統合のキラー・アーキテクチャとして期待されている。ビジネス統合システムへの拡張に関して、.NETとJ2EEの両陣営はどのような製品を投入しているのか検討していこう。

(1)SOA/BPM

 Webアプリケーションを中核としたシステム統合は、ハブ・アンド・スポークと呼ばれるモデルを採用する。これは従来のEAIから引き継いだ考え方で、異種システム環境の中心(ハブ)にWebアプリケーションを配置し、孤立したシステムとの連携を果たす通信手段(スポーク)を用意するというもの。孤島システム同士が個別にプロトコルを決めて連携するよりも、はるかに効率的で投資効果も高い。

 ハブ・アンド・スポークを実現するには、異種システムのすべてと連携できる共通のインターフェイスが必要だが、XMLをベースとした業界標準プロトコル「Webサービス」がその役割を担うとの認識が生まれつつある。標準化されたプロトコルであるWebサービスの登場によって、2004年には新たに「SOA」という言葉が大流行した。SOAはWebアプリケーションを中核としたシステム統合をもう1歩進めて、特定の業務に特化した複数のビジネス・アプリケーションを次々と呼び出す(オーケストレーション)ことで、ビジネス・プロセスを実行するというビジネス統合型アーキテクチャである。

 SOAの詳細はMSDNの技術文書「プラットフォーム非依存の次世代エンタープライズ システム構築を可能にするマイクロソフトの SOA」の該当個所を以下より参照していただきたい。

 .NETはリリース当初から、Webサービスのサーバ、クライアントの両方をビジュアル開発環境で容易に作成できる多くの機能を盛り込んでいる。つまり、通常の.NET環境でもWebサービスをインターフェイスとした疎結合型のシステム統合は可能だが、さらにSOAへと進む場合は、BizTalk Serverを採用することになる。BizTalk Serverは.NETアプリケーションにビジネスプロセス管理(BPM)やEAI、BtoB、インターネットEDIなどの機能を追加するミドルウェアだ。

 BizTalk Serverの詳細はMSDNの技術文書「プラットフォーム非依存の次世代エンタープライズ システム構築を可能にするマイクロソフトの SOA」の該当個所を以下より参照していただきたい。

図3 BizTalk Serverのオーケストレーション
イントラネット内の既存アプリケーションやファイアウォールの外部にあるアプリケーションをWebサービスによって呼び出し、それらをビジネスプロセスとして制御するのがオーケストレーションだ。この一連のプロセスをさらにWebサービスとして外部に公開することも可能(マイクロソフトWebサイト上のドキュメント「BizTalk Server 2004 新機能」の図版を元に再構成)。

 J2EEサーバで同じようにSOA/BPMを実現する場合、やはりBizTalk Serverと同様にSOA対応ミドルウェアを導入することになる。例えばWebSphereファミリーならば中心となるWepSphere Application Serverのほかに、

  • BPMミドルウェア
      WebSphere Business Integration Server Foudation
      WebSphere MQ Workflow
      WebSphere Interchange Server
  • メッセージング・ミドルウェア
      WebSphere MQ
  • EAIミドルウェア
      WebSphere Business Integration Message Broker

がそれぞれの目的に対応する製品となり、これらを組み合わせてSOAを実現する。ところで、SOAで重要なBPMを実現する根本の仕様は、標準化団体のOASISで策定されているBPELに収れんしつつある。BPEL仕様の策定作業は、マイクロソフト、IBMらが中心になっているため、BPEL対応製品の機能に大きな差が生じるわけではない。むしろ、BizTalk ServerやWebSphereファミリーといったSOA製品を選択する際に重要となるのは、その製品のコンセプトがどこにあるかだろう。

  BizTalk Serverは非常にコンパクトでシンプルな動作を狙った製品であり、コストパフォーマンスに優れている。最新バージョンのBizTalk Server 2004はVisual Studioとの完全な統合が達成され、開発生産性が向上した。SOAを導入する障壁が低いため、少ないコストとリスクで部分的にSOAを導入し、状況を見ながら適応範囲を広げていくような漸進的アプローチに適しているだろう。

 J2EEサーバの代表格であるWebSphereファミリーは、特定の機能に特化したミドルウェアを複数組み合わせてビジネス統合を目指すコンセプトだ。上述したWebSphereファミリーのSOA関連製品の多さは、既存のミドルウェア製品をWebSphereというブランドに統合しつつあるIBMの戦略を反映している。また、同社のSOAは企業の経営層に近い上流工程でビジネス・コンサルティングを重視している点も特徴の1つだ。シンプルな製品構成でSOAを目指すBizTalk Serverとは対極にあるソリューションといえるだろう。

(2)レガシー統合

 2005年以降はSOAによるシステム/ビジネス統合が主流になってくる。多くのWebアプリケーションはWebサービスに対応しているので、SOAへの統合はスムーズにいくだろうが、企業システムではレガシー資産がホスト・システムに蓄積されていることも少なくない。これらのレガシーシステムを稼働させたままSOAに参加させることは、過去のシステム投資を保護すると同時に、SOAシステム開発のコスト削減につながる。

 レガシー統合は、.NET環境であればHost Integration Serverを導入することになる。Host Integration Serverは最新バージョンの2004から、.NET FrameworkやVisual Studio .NETをサポートするようになり、.NET+BizTalk Serverで構築したSOAシステムとの連携が容易になった。Host Integration Serverの詳細については、MSDNの技術文書「プラットフォーム非依存の次世代エンタープライズ システム構築を可能にするマイクロソフトの SOA」の該当個所を以下より参照していただきたい。

 J2EE環境でも、例えばWebSphereファミリーにはWebSphere Host Solutionという同様の機能を提供するミドルウェア製品が用意されている。この製品はホスト端末エミュレータやWeb化ツールパッケージ、実行環境としてのWebSphere Application Serverなど複数のコンポーネントから構成されている。

   


統合開発環境の優位性を考察する

(1)開発ツール

 Webアプリケーション開発現場で現在、最大の問題と認識されているのは、そのアーキテクチャが複雑になりすぎて開発者のスキルが追い付かないことだ。特にJ2EEでの開発が急速に普及した数年前は、スキルの高いJava開発者不足は深刻だった。この問題を解決する方策として取り入れられたのがフレームワークだったことは前述した。しかし、現在においてもJ2EE開発者の人手不足は解消されたとはいいきれない。一方、.NETの登場以降は、開発生産性の向上を求めて新規開発プロジェクトに採用するプラットフォームとしてJ2EEよりも.NETを採用する動きが強まっているようだ。これは両陣営が提供するフレームワークの複雑さの度合いにも関係するだろうが、さらに重要なのはフレームワークを十分活用するための開発ツールの使いやすさにある。

 .NET開発ではVisual Studio .NET(以下、VS .NET)という強力な開発ツールが用意され、.NET FrameworkおよびSOA、レガシー統合まで、Windowsプラットフォームで稼働するすべてのアプリケーションを1つのツールで開発できる。@ITが2005年1月に行った読者アンケートでも、サーバサイド製品の選択動機で「開発生産性/開発環境」を挙げたのは、商用Java製品ユーザーで12%であるのに対し、Windows Server+.NETユーザーでは19.7%になっている。

図4 Visual Studio .NETのビジュアル開発環境
左ペインのツールボックスコンポーネントを中央ペインの設計画面にドラッグ&ドロップできる。設計画面は、Webページ上のコントロールをグラフィカルに表示。ロジックを作成または編集できるコード編集ウィンドウも用意されている。右ペインのプロパティ ブラウザでは、デザイン サーフェス上のコンポーネントをカスタマイズできる。開発環境には、Web アプリケーションを容易にデバッグできるデバッガも用意されている(MSDNライブラリー「Web Formsの紹介」より転載)。

 J2EE陣営でも、JSF(JavaSever Faces)を用いて各社がさまざまなグラフィカルな開発環境を提供し、VS .NETのようなWebアプリケーションの開発スタイルを目指しているが、まだ本格的な普及はこれからであり、対応する市販UIコンポーネントも.NETに比べはるかに少ないのが現状だ。

 開発者の確保についても、.NET環境は有利な立場にいる。VS .NETではオブジェクト指向言語として最新の仕様を持つC#も選択できるが、それよりも現在多数存在するVisual Basic(以下、VB)開発者を最低限の移行コストでWebアプリケーション開発に動員できるVB .NETの存在が大きいだろう。従来のVBと変わらない記法のまま、オブジェクト指向言語のシンタックスを取り入れたVB.NETは、VBからJavaへの移行に比べはるかに容易である。

 J2EEサーバ・ベンダは開発ツールの性能向上に努めており、その製品発表会の席では「VB並のGUI操作性を目指した」という発言をよく耳にしたが、この声明の背景には潤沢なVBエンジニアをJava陣営に移行させることでJava開発者不足を解消しようという意図があった。しかし、早くから無用なコーディングをせずに済む機能を取り込んできたVSの洗練度には、そうたやすく追いつけるものではない。また、いくらVB並の操作性を実現したところで、VBからJavaへの移行はプログラマにとって非常に大きな負担となるのは間違いない。開発ツールの生産性については、MSDNの技術文書「小規模から大規模システムまでをカバーするマイクロソフトのアプリケーション フレームワーク」の該当個所を以下より参照していただきたい。

 さらに、オープン系システムのJ2EEにおいて開発ツールは全体最適化されにくい事情がある。J2EEの仕様はJCP(Java Community Process)で個別に議論され承認されるので、開発ツールがリリースされた直後に新しい仕様が決定されるといったことも起こるだろう。また、データベースに強いベンダのJ2EE開発ツールは当然、データベース設計の機能は豊富になり、UML設計ツールを有するベンダの開発ツールはUMLモデリング機能に優れているといったように、各社が独自の性能をアピールする結果、ユーザーの開発ツール選択に複雑さが持ち込まれてしまう。これを嫌って汎用性の高いEclipseを使用しても、開発プロジェクト単位に各種のアドインを導入する必要があり、やはり開発環境の複雑さからは逃れられない。

 これに対し、.NET開発者はVS .NETの習得にのみ専念すればよい。このようなプラットフォームと開発環境の明快な対応関係は、オープン系のJ2EEでは得られないメリットだろう。単一ベンダの戦略に依存することになるが、.NETプラットフォームを選択するなら、オープン系システムに付きものの複雑さからは解放される。Webアプリケーション構築に際し、開発生産性や既存資産の活用、開発者の確保などを重視するならば、あえてJ2EEの複雑さを選択する必要はないだろう。なお、マイクロソフトのWebサイトでは「Microsoft .NETとIBM WebSphere/J2EEの比較」という資料も公開されている。

 前編では、.NETとJ2EE選定のポイントとして、「Webアプリケーション・サーバの技術基盤」「ビジネス統合ミドルウェア」「統合開発環境」に関して考察を行った。後編では、「クラスタリング・システム」「リッチクライアント環境」「ユーザー/サーバの運用管理」に焦点を当て、さらに検討を続ける。(後編に続く)

.NETとJ2EE、サーバサイド・テクノロジの真実
前編 .NETプラットフォームが選ばれた6つのテクニカル・アドバンテージ
後編 .NETプラットフォームが選ばれた6つのテクニカル・アドバンテージ

提供:マイクロソフト株式会社
企画:アイティメディア 営業局
制作:
アイティメディア 編集局
掲載内容有効期限:2005年5月2日
 
@IT関連記事
「Webアプリ・プラットフォームとして
Windowsを選択する7つの理由」
フリーJavaでなく、Windows+ASP.NETを選ぶ7つの理由とは?<前編>
フリーJavaでなく、Windows+ASP.NETを選ぶ7つの理由とは?<後編>

「Linuxの真実、Windowsの真実」
「Linuxの真実、Windowsの真実」indexページ
プロローグ LinuxとWindows。その本当のコストとリスクを評価するために
第1回 ファイル/プリント・サーバの基本機能比較
第2回 ネットワーク管理に不可欠なディレクトリ・サービス
第3回 Linuxの本当のTCOを考える
第4回 LinuxはWindowsより安全か?
第5回 Office互換ソフトの実力とリスク
第6回 Webサーバ・プラットフォームとしてのLinuxとWindows
第7回 大規模Webホスティング・サービスでシェアを広げるWindows+IIS
第8回 Webアプリ開発プラットフォームとしてのLinux+フリーJavaとWindows+.NET
第9回 可用性、スケーラビリティを備えたシステム開発
第10回 座談会:システム・インテグレータから見たLinuxとWindows(前編)
第11回 座談会:システム・インテグレータから見たLinuxとWindows(後編)

マイクロソフト関連リンク
「MSDNドキュメント
シリーズ プラットフォームの選択」
第1回 マイクロソフトのビジネス アプリケーション プラットフォーム
第2回 小規模から大規模システムまでをカバーするマイクロソフトのアプリケーション フレームワーク
第3回 プラットフォーム非依存の次世代エンタープライズ システム構築を可能にするマイクロソフトの SOA
第4回 Windowsエンタープライズ システムのスケーラビリティ/可用性/セキュリティ概要
第5回 ユーザー エクスペリエンス活用で情報システムの価値を最大化するマイクロソフトのクライアント ソリューション

.NET関連製品
Windows Server System ホーム
Windows Server 2003 ホーム
BizTalk Server ホーム
Host Integration Server ホーム
.NET Framework ホーム
Visual Studio ホーム
Visual C# ホーム
ASP.NET デベロッパー センター ホーム
Microsoft Message Queuing(MSMQ) ホーム
スマート クライアント デベロッパー センター
Microsoft Operations Manager ホーム
Microsoft Systems Management Server ホーム


 
@ITトップ@IT Special インデックス会議室利用規約プライバシーポリシーサイトマップ