It is a servlet. It is also a set of re-usable components assembled into a framework. You can choose to work with just the Servlet, you can choose to work with just the components or you can choose to work with both. In a lot of normal development cases, people start off with a simple servlet and tack on various components (like Connection Pooling, Cron Schedulers, User Management, Services, etc.). That is what we have done as well, however we have done it in such a way that it is very pluggable. Mix and match and use what you want to use. Ignore the rest.

それはServlet です。それは同様にフレームワークの中へ組み立てられることに関してに再利用に適したコンポーネント群です。多くの開発ケースにおいて、人々はシンプルな Servlet で始めようとし、様々なコンポーネント（コネクションプーリング、Cron スケジューラ、ユーザ管理、さまざまなサービス）を付加します。どんなに私たちが非常に追加可能なものを利用しても、それは私たちが同様に行なったことです。混成させて調和するようにあなたが使いたいことを使ってください。残りは無視して構いません。

Turbine is the for the web - Swing is not - not applicable.

Turbine は Web のためにのものです。 Swing はそうではありません - 適用範囲外です。

There is nothing in Turbine explicitly using the JTS/JTA - but can use EJB and hence these technologies. That belongs in EJB's anyways. :-)

Turbine には明確に JTS/JTA を使用するものはありませんが、 EJB とそれらの技術を使用することが出来ます。それは EJB に常に属します :-)

Turbine provides support for using and working with XML. Again, nothing preventing you from using XML within Turbine or even sending XML out of Turbine.

Turbine は 使用することと稼動することで XML への対応を提供します。復唱しますが Turbine で XML を使うことや、 Turbine から XML を出力することも阻まれることではありません。

Turbine provides excellent support for using JSP in its model of working - which is based on the Model 2 style with enhancements, such as solving the Action portion of the Model. However, we strongly suggest that you do not use JSP and seek out other alternatives.

Model２のAction部分を解決するような JSP を Model２形式の拡張において使用するときに Turbine は素晴らしい対応を提供します。しかしながら、私たちは強くあなたが JSP を使わないと示唆して外に他の選択肢を求めます。

You can use container managed security if you wish, and Turbine provides you with mechanism for application manged security, in case you need them.

望むのであれば、コンテナ管理のセキュリティを使うことができて、そして Turbine はアプリケーション管理のセキュリティのためにあなたにメカニズムを供給します。

The main problem with container managed security is that it cannot be managed from the inside of the application. Whenever you want to add/remove users to your application (or suite of them) or want to modify user's roles, you need to use whatever tool your application server provides for that.

コンテナ管理のセキュリティとの主な問題は、アプリケーションの内部からそれが管理されることができないということです。あなたがあなたのアプリケーションへのユーザの追加／削除( またはそれらの両方 )へ望む時はいつでも、またはユーザのロールを修正するには、アプリケーションサーバがその目的のために提供するどのようなツールでも使う必要があります。

Now, this could work just fine for closed-public applications and intranets, but would be really unacceptable on open-public sites, where the users need the ability to register and receive 'accounts' without human interaction.

現在、これは閉ざされた公共のアプリケーションとイントラネットのために上手く働くことが出来ました。しかし公共のサイトでは、ユーザは登録する能力を必要としているので人間的な相互作用なしには、『アカウント』を受け取る場所で受け入れられないでしょう。

Currently Turbine supports the latter model - application managed security. This is because if it didn't have it, many people would have to write code to provide it. That's why we created SecurityService in a cooperative effort.

現在 Turbine は後のモデル - アプリケーション管理のセキュリティをサポートします。これはそれがなかったならば、多くの人々がそれを提供するためにコードを書かなければならないだろうからです。それは私たちが協力的な成果で SecurityService を作成した理由です。

On the other hand, you don't need to write any code to use declarative container managed security. You can restrict access to the Turbine servlet with the usual web.xml magic. If you wish to use programmatic container managed security code, there is relatively very little code to write. You need to create your own SecureScreens (probably extending VelocityScreen) and SecureActions that contained code that calls the HttpServletRequest getUserPrincipal and isUserInRole methods. above.

他の方面では、あなたは説明したコンテナ管理のセキュリティを使うために少しもコードを書く必要がありません。あなたは普通の web.xml の魔法で Turbine Servlet に対するアクセスを制限することができます。プログラム的なコンテナ管理のセキュリティコードを使うことを望むのであれば、書く分にはとても少量のコードがあるだけです。あなたは（おそらく VelocityScreen を拡張して）HttpServletRequest getUserPrincipalとisUserInRoleメソッドをコールする自分の SecureScreens と SecureActions を作り出す必要があります。