The Server Side.comの記事翻訳です。
http://www.theserverside.com/tt/articles/article.tss?l=OSGiforBeginners
最近何かと話題のOSGiを、勉強がてら翻訳。
JavaOne2008でも、話題だったらしいし。
May 2008 Discussion
Introduction(導入)
The Ig Nobel prize ceremony features a few very interesting concepts, apart from the Ig Nobel prizes themselves. One of them is a chance for the literati to explain a concept in twenty-four seconds, followed by a seven word summary.
イグノーベル賞の式典には、イグノーベル賞とは関係ないですが、
いくつかのとても興味深いコンセプトがあります。
その一つは学者に対して、7つの語句だけで概要を説明したあとで、
24秒間でコンセプトを説明する機会を与えるというものです。
This is a brilliant idea, and one every project should consider as a challenge to fulfill.
これはすばらしいアイデアであり、
すべてのプロジェクトで実施してみることを考えるべきです。
OSGi has been mentioned quite a bit in the industry lately, with Equinox becoming a top-level project for Eclipse, Felix being used as a container for Sling and Glassfish V3, and Spring-Modules being released. That said, a lot of people who are unfamiliar with OSGi ... are still unfamiliar with it, no matter how much the people who use OSGi regularly know about it.
OSGiは、業界で最近かなり話題になっています。
例えば、Eclipseのためのトップレベルプロジェクトとなった「Equinox」や、
SlingやGlassfish V3といったコンテナで使われている「Felix」や、
「Spring-Modules」などがリリースされました。
とはいうものの、大勢の人がOSGiには馴染みが無いことでしょう...
どんなに使っていたとしても、それでもなお、通常OSGiについては知らないものです。
So I, as a non-OSGi advocate, would like to take some time to try to explain OSGi to the people who don't know about it - a novel idea, apparently - along with some example code to help people get started. Again, I'm not an OSGi advocate (well, not from the standpoint of being part of OSGi.) I'm just someone who thinks OSGi has viability, except that it's got really poor documentation unless you're so good at it that you don't need the introductory materials.
それでは、私がOSGiの非支持者として、
OSGiの明らかに奇抜なアイデアを知らない人に説明してみようと思います。
説明には入門の手助けとなるサンプルコードを使いましょう。
かさねて言いますが、私はOSGiの支持者ではありません。
（つまりOSGiのまわしものではないという立場です。）
私はただ、OSGiは存続の可能性はあると思っているだけです。
ただ、ほんとに貧相な紹介ドキュメントしかないことがネックではあります。
First, I'll give you the seven-word explanation, then the twenty-four second explanation (transcripted), and then I'll try to explain the whole thing.
まずは、7語で説明しましょう、それから24秒で説明します。
そしてその後、すべての説明をすることにします。
The Seven-Word and Twenty-Four-Second explanations of OSGi （7語と24秒でOSGiを説明する）
OSGi is a component framework for Java.
OSGi、は、Java、のための、コンポーネント、フレームワーク、です。
The twenty-four second explanation: OSGi is a framework for Java in which units of resources called bundles can be installed. Bundles can export services or run processes, and have their dependencies managed, such that a bundle can be expected to have its requirements managed by the container. Each bundle can also have its own internal classpath, so that it can serve as an independent unit, should that be desireable. All of this is standardized such that any valid OSGi bundle can theoretically be installed in any valid OSGi container.
24秒の説明：OSGiは、Javaのためのフレームワークです。
OSGiでバンドルと呼ばれるリソースのユニットをインストールできます。
バンドルは、サービスや実行中のプロセスからエクスポートすることができます。
そして、それらの依存性は全て管理します。
ここでいう依存性とは、コンテナによって管理される要件があると予想できるバンドルです。
それぞれのバンドルは自分自身の内部にクラスパスを持つこともできます。
そして必要とあらば依存ユニットとして稼働することができます。
この全てが（理論上は）すべてのOSGi準拠のバンドルおよび
全てのOSGiコンテナにインストールできるように標準化されます。
Rats. Twenty-seven seconds, no matter how fast I run through - I just can't talk quickly enough. What's worse, the explanation doesn't explain why one wants a module system in the first place.
くそっ！！24秒、どんなに駆け足でやっても、話し足りないなぁ。
ひどいことに、この説明ではそもそもなぜモジュールシステムが必要とされているのかを説明していません。
Why a Module System? （なぜモジュールシステムが必要なのか？）
Module systems provide version support for distributed bundles (where "bundle" goes way beyond "OSGi bundle" - I'm using the term to refer to any application.) Dependency hell is also an issue; lifecycle is ... interesting.
モジュールシステムは、分散されたバンドルのバージョン管理機能を提供します。
（"バンドル"は、"OSGi バンドル"をはるかに超えますが、
どのようなアプリケーションでも参照するためにこの用語を使っています。）
依存性の地獄は、常に問題となります。ライフサイクルは、、、興味深いものです。
All of these things are important; versioning still hasn't made it into web services, EJB versioning is enforced via JNDI, but few use it (nobody in the wild that I know of), jar dependencies are managed normally with parallel jar deployments (except for JCA and WARs, both of which have different ways of managing dependencies).
これらのすべてのことは重要です。
Webサービスの中ではバージョニングはまだ作られたことはありません。
EJBバージョニングは、JNDIを経由することを強制します。
しかし、あまり使われていません（私が知っている限り、誰もいません）、
Jarの依存性は、普通に管理されます。
Jarのデプロイと並行して。
（JCAやWARは除きます。それらはともに異なる方法で依存性の管理をします。）
Java EE has solutions, although not necessarily good ones: WARs and JCA can contain jar files, EJB jars can refer to other jar files through their manifests, and of course app servers can provide a higher-level class repository; versioning is provided through JNDI as long as you're not using different versions of the same web app or web services. Lifecycle exists for webapps (load-on-startup servlets, context listeners) and JCA, but EJB 3.1 might have a lifecycle mechanism - it's not sure yet.
JavaEEは、必ずしも良いものではありませんが、これらに対するソリューションを提供しています。
WARやJCAはjarファイルを保持することができます。
EJB Jarはマニフェストファイルで他のJarファイルを参照することができます。
そしてもちろん、アプリケーションサーバーは、
高いレベルのクラスリポジトリを提供することができます。
同じWebアプリケーションや同じWebサービスで、異なったバージョンを使わない限り、
バージョニングはJNDIを通して提供されてきました。
ライフサイクルはWebアプリケーションで存在しています。
（load-on-startupサーブレットやコンテキストリスナーのように）
そして、JCA、しかしEJB３．１はライフサイクルのメカニズムを持つことになるでしょう。
（まだ未定ですが）
And we all know that Java EE is a hammer that fits everything.
そして、我々が知っているのは、
JavaEE は何にでも良く合うハンマーであるということだけです！
OSGi and JSR-277 are attempts to standardize module deployments for Java, without forcing a Java EE mindset, and without Java EE's weaknesses regarding dependencies and versioning and - for that matter - lifecycle. Since this is an OSGi article and not a module article, we'll focus on OSGi...
JavaEEの理念を使わずに、Javaのモジュール配備を標準化することを企てています。
そしてこの計画では、JavaEEの依存性やバージョニング、
（ついでに）ライフサイクルに関わる弱点に影響されることもありません。
この記事は、OSGiの記事であり、
モジュールの記事ではありませんので、そろそろOSGiにフォーカスしましょう！
