- - PR -
EJB3.0の紹介記事に対して。。
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2004-05-21 12:11
最近は商用製品がオープンソースの後をついて行っているような気がします。
EJB3は確かによくなった気はしますが、ただ、記事だけでの話なら、 POJOをSessionBeanとして使うためには ・＠Sessionというアノテーションをソースコードに追加 ・他の既存のDDに書いていた情報をソースコードに追加（これってXDocletのマネ？） する必要があり、これはあまりきれいだとは感じられません。 これって正にAOP（Attribute-Oriented-Programming）の方向に向かって走りますよね。 ただ、既存のXDocletもそうですがこの方法ならソースが汚くなるし（←これは人により異見がありえますが）、 ビジネスロジックとそれ以外の部分が混在する事になって各担当者（各機能の開発者及び配置者）の分業が しづらくなる上に前述の「それ以外の部分」の変更だけでも ・ソースの変更と ・再ビルド が必要になりますね？そもそもそんな事を避けるためにEJBではDDを用意していたのではないでしょうか？ （まあ、ソースコードの中でビジネスロジック実装の部分とアノテーションの部分は分離されるんだと言う考え方もあり得ますが。。） それと、細かい事ですが上記のようなアノテーションが入っているソースってPOJOと言えるんですか？ 不純物がたくさん挿入されているとの感じですが。 私としてはもう一つのAOP（Aspect-Oriented-Programming）がより正しい方向ではないかと考えられます。 例として、JBoss4ではJBoss AOPと言う名前で既にPOJOをそのままEJBとしても使えるようにする仕組みがあります。しかもPOJOには 何の修正もアノテーションの追加も不要です。（この機能はStandalone AOP Frameworkと言う名前で単独のライブラリーとしても使えます。） 実は私はこれにもっと興味を持っています。Martin Fowler氏の新しい用語「Dependency Injection」もAOPの違う表現であるだけのような気がしますし。。 他に気になる事は、本質とは離れるかも知りませんが ・EJB3.0って、上記の話だとJDK1.5に依存する事になる。なら、いつごろ使えるんだ？ です。 余談： ・EntityBeanにアノテーションを入れてマッピングなどの設定を行うって事は今のHibernateのPersistentクラスにXDocletを入れて使っている事と ほぼ変わりませんね？ 以上、書いていたら長くなりました。申し訳ございません。 | ||||
|
投稿日時: 2004-05-21 13:00
元記事はこちらですね。
http://www.atmarkit.co.jp/fjava/kaisetsu/j2eewatch02/j2eewatch02.html 最近のJCP(J2EE)の動きは新技術の標準化が目につきますよね。 今回のEJB3.0の動きもJBossAOP/XDoclet/Hibernateという３つの Enterprise機能などをBEAとIBMとSUNが取り込む為の手段だと思います。 結果的にBEA/IBMの傘下にある開発者の利益になるから良いことだとおもいますが、 JBoss陣営の中には差別化要素が減るために面白くない向きもあることでしょう。 アノテーションはリモートインタフェース・ホームインタフェース・ローカルインタフェース やデプロイメント用コードを書くよりよっぽど綺麗になる可能性があると思います。 EJB3.0がリリースされるのは来年以降でしょうし、実際に使い物になるのはもっと先だとは思いますが、SOAPやSDOのような標準策定の変な動きよりよっぽどましだと思いますよ。 [ メッセージ編集済み 編集者: zaxx_MD 編集日時 2004-05-21 13:03 ] | ||||
|
投稿日時: 2004-05-25 10:35
確かに、それはそうですが、それって今のXDocletと何の差もないのではないでしょうか？その上、XDocletはコメントとして書きますのでJDKのバージョンには関係ないですが（JDK1.4以下ではただ無視される）それがアノテーションとなるとJDK1.5以上に限られてしまうし。。 そもそもそんなアノテーションが入っているソースがPOJOかよ？と言いたいですがそれがJDK1.5なら仕様としてPOJOの範囲に入るとの事でしたらそれはそれで納得するしかないかとは思います。 今のXDocletもそうですが、何か設定の変更があった場合でも（例えばトランザクション設定の変更、JNDI名の変更など）再ビルドが必要になりますよね。これは開発者としてはあまり苦にならないかも知りませんが（でも、確かに効率は下がりますね）運用及び再利用の時期になってコンポーネントの配置者の観点から見るとかなり面倒です。開発者はDDとか読まなくてもソースの中で何でも解決できるから楽かも知りませんが。。 それならそもそもなんでEJBでDDって存在するんだよ？と聞きたいですね。開発時にはアノテーションで書くけど結果的にはDDとかが生成され、配置者は再ビルドはしなくてそのDDだけをいじればいいとの考え方もあり得ますがその場合、何かの理由で再ビルドされたら配置者のせっかくの設定はパーになりますね。 ソースはビジネスロジックに集中させようといいたいですけど。。 | ||||
|
投稿日時: 2004-05-25 15:13
うーん・・確かに。
ただ、コメントも純粋にコメントだけが書かれる方が自然ですよね？ コンフィギュレーションとビジネスロジックを分離してポータビリティを高めるという思想を実現しようとしても今のPOJOではどこか綻びてしまうからJDK1.5前提ということだとは思います。 その思想自体に意味が無いという指摘もありますが・・・ | ||||
|
投稿日時: 2004-05-26 07:31
JCPはXDoclet云々を実現しようとしているのではなく、メタデータを利用したAOPを実現しようとしているだけです。
| ||||
|
投稿日時: 2004-05-26 11:04
（Java1.5の）メタデータを利用したAOPでEJBを実装しようとしている
↓訂正 （JDK1.5の）メタデータを利用したAOPでEJBを実装しようとしている ・・・じゃなくて？ #とうとう「大きいベテラン」と表示されてしまった・・・もっと仕事しないと・・・orz [ メッセージ編集済み 編集者: zaxx_MD 編集日時 2004-05-26 11:06 ] | ||||
|
投稿日時: 2004-05-30 07:24
それは知っています。が、その方向性が正しいかの疑問ですが、そもそもEJBにDDがある理由はそんなビジネスロジック以外の部分をソースコードの中で管理するのがよくないとの発想からではなかったんでしょうか？ DDが管理しやすいかどうかは別途として、少なくともDDは再ビルドをしなくてもビジネスロジック以外の設定を変更できるメリットがあります。再ビルドってどうって事無いじゃん？と思う方もいらっしゃるとは思いますが規模が大きくなり、開発者と配置者が異なって来るとこれは問題になります。配置者がソースコートを読み、アノテーションを修正して結果的にDDが変わると言うのは現在のXDocletと同じ手順になりますが配置者にそこまでのスキルを要求する事になります。（常配置者はあまり詳しくありません。少なくとも私の経験によりますと、）勿論、配置者はDDだけをいじるという手もありますが、そもそも自動生成されたDDって人間には読みづらいし、何かの修正があり、そのコンポーネントが再ビルドされた瞬間、配置者はゼロからやり直しになります。配置者のDDの修正をちゃんと管理して次回の再ビルドにその修正を反映するっていう手もあり得ますが現実的にはそんな履歴管理って出来ないし、トラブルの元になりがちです。 まあ、こんな観点から、EJBでのアノテーションの使用をあまり望ましくないと思っているだけです。この観点からすると逆にJBossAOPが正しい答えかなと思われたりもします。 | ||||
|
投稿日時: 2004-05-30 15:27
僕も同感です。 アノテーションによってEJBコンポーネントの配布にはソースコードを含める ことが必須になってしまいますし... 今関わっているシステムでは、他チームが開発したEJBコンポーネントを 再利用することが頻繁に行われているのですが、再利用する際はDDを 変更することがよくあるので、DDによって(ある程度)カスタマイズできる と言うのは大きなメリットだと思っています。 あとEJBコンポーネントを有償で配布している場合なんかも、ソースコード を配布することになってしまって、良くないのではないかとも思います。 ついでにEJB2.0までとの共存ってどうなるんでしょうね。 EJB1.1から2.0に変ったときも結構変更がありましたけど(特にEntityBean)、 こう毎回毎回大幅に変ってしまうと、安定技術として定着することなく 終わってしまうような気が... | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。