オープンソースCMS「DotNetNuke」のセットアップ
前回はMicrosoft Web Platform Installerを利用して、DotNetNukeとWebMatrixをインストールする方法を紹介した。今回は、DotNetNukeのインストール方法を紹介する。
Articles
ブックマークされました！
ブックマークがエラーになりました。もう一度お願いします。
Nuxeoのその後 : PythonからJavaへの移行
作者 Charles Humble , 翻訳者 大田 緑 - (株)チェンジビジョン 投稿日 2010年9月30日
2000年に設立された Nuxeo は、オープンソースのエンタープライズコンテンツ管理(ECM) を専門にする会社です。Nuxeoは、2006年に、核となる技術プラットフォームをPythonからJavaに移行すると発表しました。4年経った今、この転換がどのような結果になったかを明らかにし、ECM産業の中で新しい技術の積み重ねとそのポジションを探るため、InfoQはNuxeoのCEO、Eric Barroca氏に話を聞きました。さらに、動的と静的型付け言語の相対的な利点について議論しました。
ECMのマーケットはよく知られているパターンに従いました。初めは、Documentum、Interwoven、Vignette、Stellentなどの専門の独占的なベンダによって支配されていました。マーケットがさらに確立されると、大きくて一般的なソフトウェアベンダ、FileNetのIBM、SharepointのMicrosoftなどが入ってきました。NuxeoやAlfrescoなどのオープンソース企業も、重要なプレーヤーになりました。もっと一般的な言葉で言えば、Barrocaによると、ECMツールはますます必要なものになりました。
誰もが、いつの日か法的な公開が条件になることを認識しながら、ますます多様になった電子保存データを管理しようとしています。だから、ECMが必要な技術空間になることは驚くことではありません。Microsoft Sharepointは、基本的なコンテンツ管理機能とコンセプトをメインストリームのビジネスユーザの手に押し込みます。オープンソースの成熟と成長、そして、最近実証された産業の標準もまた、顧客が時間と金銭的なリソースを投資することを推進していると私たちは信じています。
同時に、ビジネスは新しいシステムを実装し、技術を一新しようとしています。1990年代に構築された製品は、今では役に立つ製品ライフサイクルの終わりに来ています。コンテンツは、今、携帯電話、ソーシャル、オープン、そして、相互運用が可能なものの世界で作られています。Nuxeoのプラットフォームは、これらに合うように設計されています。
この核となるアーキテクチャは、モジュールシステムを提供するOSGiの主な技術スタックとしてJava EEを使って構築されています。Nuxeoは、使用されるコンポーネントモデルとしてランタイムを構築しました。例えば、サービスやクライアントがその中、または、外でEJBの使用を使うことを切り替えるようにしました。
この製品は、以下の通りJava EE標準を多用しています。
- ストレージの抽象化のためのJDBC、JPA、そして、JSR-170
- XAトランザクション管理のためのJTAとコネクションプーリングのためのJCA (アプリケーションサーバによってまだ提供されていない場合はApache Geronimo)
- WebEngineとREST APIのためのJAX-RS
- UIレイヤのためのJSF (Seam と RichFacesをつなぐ)
"これらの標準は、標準化されていないけれども、だいたいどのような問題でも解決する素晴らしいコンポーネントによって、うまい具合に完成しています。" とBarroca氏は言いました。"Lucene、Hibernate、Eclipse、そして、多くのもっと小さなコンポーネントは、今日アプリケーションの構築を容易にしています。Pythonは様々なケースで優れていると私たちは考えます。ただ私たちが目標としていたビジョンやマーケットに対して、正しいプラットフォームではなかったのです。"
Nuxeo製品は、合計約100個のライブラリを使います。上記でBarroca氏が引用したライブラリと同じく、他の重要なライブラリがあります。プロセスエンジンとしての jBPM 、ウィジェットを含むこととソーシャル機能のための OpenSocial と OAuth (Apache Shindig)、CMISのためのApache Chemistry。
ビルドシステムは、ユニットテストフレームワークとしての JUnit と共にMaven と Hudsonをベースにしています。この製品は、現在、JBoss、Tomcat、Jettyをサポートしますが、プラットフォームのほとんどはそのままOSGi上で動きます。Nuxeoによると、新しいアプリケーションサーバのサポートを追加するのは、2、3日という比較的短い日数で終わる作業です。
Javaライブラリの範囲と深さは、Javaに変更する主要な原動力の一つでしたが、Barroca氏は他の理由も挙げました。
マーケット: Javaアプリケーションのマーケットは巨大です。あらゆる企業がJavaを知っています。ほとんどの企業ではすでにJavaアプリケーションを動かしています。多くの企業がITのためにJavaを必要としています。あらゆるシステムインテグレータは、広範囲に渡るJavaの知識を持っています。
コミュニティ: これも巨大です。例えば、Java Apache コミュニティはおびただしい数があります。JavaOne、ApacheCon、Devoxx、JazoonなどJavaに関する毎年恒例の大きな大会と数百という小さな大会があります。
仕様: Javaの世界の多くの技術は、たくさんの実装とリファレンス実装を持つ公開された仕様に基づいています。これによって、クリーンな仕様、相互運用が可能なコードが生み出され、実装者が最善を尽くします。私たちはまた、ハイレベルなツールを利用できることで恩恵を得ています。VM本体から、デバッグツール、IDE、モニタリング、パフォーマンスベンチなどがあります。
Barroca氏は、再構築されたプラットフォームとオープンソース開発モデルがECMの場所に新しいマーケットを開いていると論じました。Nuxeoは、そこで有利な立場にいます。
ISVの新しいカテゴリでは、コンテンツアプリケーションを作って販売するために、ビジネスの知識をソフトウェアにパッケージ化するECMプラットフォームアプローチを使っています。このような例は、建設プロジェクト管理やバイオテックや生命科学の臨床実験管理から、州政府や地方自治体の指揮統制センタのソフトウェアまで、複数の産業と機能の範囲を超えています。
ソフトウェアのオープンソースの側面と組み合わされた私たちのプラットフォームの順応性や特徴の範囲は、コンテンツアプリケーションのアーキテクトや開発者の人生を容易にします。この開発モデルは、新しい方法でコンテンツアプリケーションを構築することを可能にします。その方法は、より簡単で、クリーンで、速いものです。
オープンソースECMはまた、コンテンツ管理のマーケットで需要の全く新しい源を動かしています。以前、非常に高い先行投資が必要なため、または、アプリケーション構築やカスタマイズを制御できないためにECMを展開していなかった企業が、今、新しい選択肢を持っています。
NuxeoでJVMプラットフォームを使うことができる1つのアプローチは、Jythonを使うことでした。Jythonは、JVMをターゲットにするJavaで書かれたPythonの実装です。しかしながら、Nuxeoはこのことを検討しませんでした。
私たちのビジョンを実現する走り書きのようなものから完全なプラットフォームを設計し、構築するために、私たちは、時間をかけて実際にECMのソリューションを構築した6年間の経験を使いたいと考えました。これは、単なる言語の変更ではなく、プラットフォームの変更でした。私たちは、開発者のために開発者が設計した、完全なECMのプラットフォームを作り出したかったのです。これは、あらゆるベンダが話しているけれども、誰も実際に技術的に実現していないECMのビジョンを実装することでした。この分野で独占的な多くのベンダの成長戦略ではありますが、すでに手に入れているものでソフトウェアを構築しようとする場合、プラットフォームを持つのではなく、ソフトウェアスィートを持ちます。ここ4年間で、私たちは、コンテンツアプリケーションを作るための完全な技術的プラットフォームを構築することができました。
プロジェクトが元のNuxeoシステムの再設計や書き直しだと考え、私たちは2つのシステムがどのように比較されるかについて少し調査ました。
パフォーマンスに関しては、どの測定基準を取るかによりますが、10倍から100倍以上になると言えるでしょう。機能に関しては、既存の範囲の約4倍になります。開発者の互換性と使いやすさに関しては、ほとんど同じですが、より多くのツールと経験があります。私たちは、古いプラットフォームで持っていた能力の3倍ではなくとも、2倍にできます。
最初の移行作業は、55人の会社で1年以上かかりました。Barroca氏は、開発者にしてだいだい1年で10人から20人だと見積もりました。
..貢献と継続してきた開発を含むとだいたい150-200人年かかりました。しかし、私は、ソフトウェア開発を人年で測るのは本当は好きではありません。会社はもちろん、開発者の間で「開発者の人年」の不変の価値のようなものはないからです。それに、私たちはかなり真剣な開発チームを持っていました。
私は、Nuxeoの既存の顧客がこの変化にどのように反応するかにも興味がありました。Barroca氏は次のように言いました。
インストール基盤の約80%はこの変更に対して問題ありませんでした。移行したくない企業は、コミュニティの力によって継続するサポートを確かなものにすることで前に進みました。これは、オープンソース開発モデルの美学です。ユーザや開発者の献身的なグループがあれば、技術は生き残れます。これが「将来の保証」の利点です。
Nuxeoでは、 かなりPythonとJavaを使いこんでいたので、私たちはこの2つの言語の利点について議論しました。一般的に、動的言語は本質的により多く表現するため、コードの中でより速くなると言われています。静的言語は、開発で省いた時間がテストで失われるという反論を弁護します。型情報がない場合、テストが難しくなり、動的言語は大抵静的型付け言語よりも遅いため、展開するにはよりコストがかかりることになります。Barroca氏が言いました。
Nuxeoでは、何千ものクラスと何十万ものコードから成る大規模なアプリケーションを書いて、動的と静的型付け言語(PythonとJava)の両方を実行してきました。そこで、私たちは疑いなく言うことができます。静的型付け言語は、そのようなアプリケーションにふさわしい言語なのです。静的型付け言語の中で、コードの効率的な静的分析を実施できます。これによって得られるものは、以下の通りです。
- 適当に自動完了するIDE
- 全てのクラスの任意のメソッドやフィールドの使用方法をIDEが全て知っているので、かなり改善された検索とリファクタリングが可能
- 数多くのコンパイル時のチェック
- コードの中のパターンや不具合を見つけるツール
- コードの中で使われる実タイプに基づいてドキュメントを抽出するツール
動的型付け言語の中の大多数のケースにおいて、メソッドは、実は常に同じタイプの引数を受け取ります。動的なことで実際にもたらされるのは、引数の型をタイプするのが少なくなることだけです。しかし、静的型付け言語の中で、型を明示することが妨げになることはほとんどなく、適切にドキュメント化されたコードとして扱われます。
これが当てはまらずに本物のポリモーフィズムである場合、現在の静的型付け言語は、動的型付け言語の利益をすべてではないがいくらかは手に入れるために、ジェネリクスを利用できます。
Python、JavaScript、Rubyなどの動的型付け言語で時々見られる別の利点は、振る舞いを追加するために、オブジェクトのインスタンス、またはクラスでさえ、ランタイムにパッチをあてられることです。(Pythonでは、これを「モンキーパッチ」と呼ぶことがあります) これは良さそうに見えるかもしれませんが、コードの理解、静的分析、デバッグ等に関しては、実にひどいことです。何かを解決することには役立つ一方で、長期的に見てほとんど良いことはありません。
最後に、動的型付け言語は、型を知らないオブジェクトのフィールドやメソッドを調べるリフレンションツールになります。
しかし、JavaはJava5からこれらの機能もサポートしています。だから動的なことは、ここで静的であることよりも利点がある訳ではありません。
Barroca氏は、最近リリースされた、また、近々公開されるJava EE 6とJava SE 7の技術を試すのを楽しみにしています。これらの技術には、モジュールシステム、JSF 2、Bean検証、メディアコンポーネント、そして、新しいNIOライブラリが含まれます。Barroca氏は、自分たちの製品にとってJavaが最高の技術だと確信しています。
ランタイムから、UIまで含む非常にモジュール化されたハイレベルなレイヤまで、私たちは、自分たちが作り出した技術をとても誇りに思っています。私たちは完全にECMのプレーヤーとしての立場にいるのであまり明らかにされていませんが、多くのJavaアプリケーションの利益になるプラットフォームの優れた部分があります。拡張システム、Seam/JSFベースのモジュール式UI、配布アセンブリエンジン、そして、さらに数多くのコンポーネントは、モジュール式Javaアプリケーションを作るときに非常に役に立つ重要な技術です。Nuxeoベースのアプリケーションでカスタマイズする場合、カスタマイズするためにUIをつつきまわすのではありません。プラグインを使ってカスタマイズするのです。これは、非常にオープンで拡張性のあるモデルです。
No comments
スレッド表示 返信