InfoQ ホームページ 設計/アーキテクチャ に関するすべてのコンテンツ
-
進行中の相互運用
あまり知られてはいませんが、非常によく使用されている2つのマネージド環境(JVMとCLR)は実際には、共有ライブラリセットにすぎません。それぞれが実行コードにメモリ管理やスレッド管理、コードコンパイル(JIT)などのサービスを提供しています。このため、同じオペレーティングシステムプロセス内でJVMとCLRの両方を用いることは大きな問題にはなりません。どのプロセスでも、ほぼすべての共有ライブラリをロードできるためです。
-
Spring WebサービスについてArjen Poutsma氏に聞く
InfoQのStefan Tilkov氏は、Spring WebサービスクリエータであるArjen Poutsma氏と一般的なWebサービスについて、とりわけSpringサポートについて話をする機会を得ました。
-
クライアント/サーバーでの Eclipse RCP と OSGi
イリノイ州シカゴの RPC Software は、自社製品の基盤にオープンソースソフトウェアを使用することで、この市場での成功を収めています。RPC Software は、競合他社よりも、早く、低コストでソリューションを提供するために、Eclipse RCP (リッチクライアントプラットフォーム)、DotProject、および SugarCRM などの技術を活用しています。この導入事例では、これらの技術の中身、この事例から得られた開発知識、および教訓を紹介します。
-
Spring 2.0: 最新情報と Spring 2.0 が重要な理由
この記事は 2 つのパートに分かれています。パート 1(この記事)では、Spring 2.0のコアコンテナ、XML 構成拡張、AOP の強化、Java 5 に特有の機能について記述します。
-
リッチクライアントテクノロジーとしてのWPF
この記事では、WPFとその他のテクノロジー、たとえばAjax/DHTML、Swing、そしてFlashを比較します。そして、Javaをベースとしたバックエンドのサービスを例として用いて、WPFフロントエンドを構築してリッチクライアントとして役立たせるいくつかのシナリオをお見せしたいと思います。
-
MapReduceとHadoopの将来について、YahooのDoug Cuttingにインタビュー
このInfoQスペシャルインタビューでは、YahooにおいてHadoopがどのように使われているか、その開発におけるチャレンジ、そしてプロジェクトの将来的な方向性についてCuttingが語ってくれています。
-
今日のDDDの重要性についてEric Evans氏に聞く
ここに掲載したインタビュー記事は、無料のダウンロード書籍『Domain-Driven Design Quickly』からの抜粋(6章)です。このインタビューの中で、Eric Evans氏はDDDをシステム開発の現状に当てはめ、今、DDD(Domain-Driven Design、ドメイン駆動設計)が重要とされる理由について説明しています。
-
事例研究:IPテレフォニー統合
2回目となるInfoQの事例研究では、テレフォニー分野の興味深いソリューションに目を向けます。本事例研究では、LiteScapeのソフトウェアソリューションの内容に注目し、まず要求事項から始め、Javaおよび .NET実装のアーキテクチャ面の概要に触れ、WebEX/LiveMeetingと電話との統合、Java/.NET統合の相互運用性、同じマシンにインストールされたシステム間の通信におけるHTTP通信とIPC通信の比較といったプロジェクトの興味深��技術的側面をいくつかクローズアップしながら、最後にプロジェクトから学んだ総括的な教訓について説明します。
-
レガシーコードのユニットテスティングにロギングの継ぎ目を利用する
ロギングを使用して、レガシーコードのユニットテストを簡単にすることができます。また、クラスのロジックを変更したり、振る舞いを変えることもありません。
-
SOAガバナンスの役割
この記事では、成功するSOAガバナンスのための役割のセットの将来性について説明します。具体的には、「SOA ドメインアーキテクト」、「SOAプラットホームアーキテクト」、「サービスデザイナー」、「ビジネスサービスオーナー」、および「テクニカルサービスオーナー」の役割についてです。
-
ボックス--パフォーマンス・ボトルネックを探し出す近道
パフォーマンス上の問題���報告される時、防御手段に凝り固まったコメントがついてくることがとても多く、そして、そんなコメントのほとんどは、どこから作業を始めるべきかを理解する上で何の役にも立ちません。このジレンマに直面し、根本的な原因から推量し始めるチームも珍しくありません。ここで「ボックス」の登場です。ボックスはシステム全体を抽象化した小さな図式です。パフォーマンス・ボトルネックの実情を思い出させてくれます。厳密な調査と併用すれば、ボトルネック発見から当て推量を排除するのに役立つでしょう。