/etc/login.defsをいじると、suでrootになれるユーザを制限できるのですか。なるほど。
「EJBは面倒だからだめ」と言うとき、欧米ではEJBをやった人が「やっぱりだめね」というのに対し、日本では導入しようとしている人が「やっぱりだめね」ということが多いように感じます。確かにEJBは面倒な部分があるので、それが理由なら問題ないのですが、日本の理由は本当にそうだろうかと考えます。
Servlet/JSP/Tomcat/Strutsは日本でも広く受け入れられました。でも、これらも同様に面倒です。XML configuration filesを第二言語のように書いたり、OOPの不自由さやテストの難しさ、デプロイの手間は本質的にはEJBと変わりません。なのになぜ、EJBだけ敬遠されるのでしょう。
EJBの利点として、トランザクションやキャッシュ・分散オブジェクト・コンポーネント化・O/R mappingなどが挙げられますが、これらは技術的課題で、enterpriseとしての真の課題はビジネスロジックの分離（ほかの何物にも関わらないようにビジネスロジックを孤立すること）にあります。そこで危惧するのは、日本ではそもそも「ビジネスロジックの独立というのが受け入れられていないのではないか」という命題です。
まず、その技術的問題として、Javaの歴史が浅いことがあります。第一フェーズとして、CGIからJavaへの移行、もしくは、そもそもないところ(nothing)からJavaの導入がだいぶ進んできました。次は第二フェーズで、旧式のJavaから最新のJavaへの移行です。これが始まろうとしている感じで、ビジネスロジックの独立はこれからの問題ともいえます。
もうひとつ技術的問題は、開発体制・技術者にあります。Viewを中心としたEvent Drivenがまだまだ主流ではないでしょうか。たとえば、開発組織を画面ごとに割り当てていたら、Event Drivenになりがちで、ロジック云々は難しいでしょう。また、Visual Basicから移行してきた技術者が、Windows GUIプログラミングの技術レベル（あえてレベルといいますが）のままいては、ロジック云々の動機は出ないしょう。つまり、StrutsのActionServletをウィンドプロシージャにみたててクラサバをやっているわけです。
次に、ビジネスプロセスの問題があります。欧米では結構、業界industryごとにセグメントが分かれていて、金融なら金融、流通なら流通と、開発もindustryに特化しがちです。一方、日本のSIは幅広く手がけます。また、日本のユーザは細かな点に気を配り（気にして）、しかも、一社一社プロセスが異なるので、共通のビジネスロジックの抽出が難しいのかもしれません。この点は、ERPパッケージが欧米のままでは日本に受け入れられないのと共通する点でしょう。
というわけで、ビジネスロジックの分離・Middle Tierの発想の土壌がない（日本にあわない）のであれば、EJBよりも面倒を減らしたIoC container/Spring/AOP/Hibernateなども日本では受け入れられないのではと考えをめぐらしています。
勉強になりました。