> Personally I think it is a very good approach to use stateless SessionBeans as a >kind of firewall to the session. You can avoid too much traffic over your >networkcable. However, it makes no sense to me to have such a flexible solution and >then not using all the benefits you can gain. > > If you have only session beans (no data persist in here) and you do not have any >underlying concept for persistent storage of your data (EntityBeans) why do you want >to use EJB-Technology? *snip* How about just using stateless session beans for the sake of load-balancing, fail-over, instance pooling and connection pooling and other nice features a good EJB-server might provide you with? Even if you�re not using Entity Beans, IMHO EJB has a lot in store. Also, my personal opinion is that Entity Beans is the least mature part of a still very young technology. They are way too much modelled with relational databases in mind (findByPrimaryKey anyone?). To my thinking a more abstract layer providing a object oriented wrapper of whatever resources (relational databases, object databases, legacy, filesystem ...) you have would have been a lot better. But then again all emerging technologies in this field seems to be developed to solve the immediate problems of e-commerce, and if you by chance want to use technology for some other purpose you're in for some serious tweaking. And - yes, that is what I'm spending my time doing these days ;-) Marcus Ahnve Sun Java Center Sweden
begin:vcard n:Ahnve;Marcus tel;cell:+46-(0)70-723 90 73 tel;fax:+46-(0)8-623 90 05 tel;home:+46-(0)8-656 48 89 tel;work:+46-(0)8-623 90 73 x-mozilla-html:TRUE url:www.sun.se org:Sun Microsystems AB;Sun Java Center adr:;;Esbogatan 18;Kista;Stockholm;164 94;Sweden version:2.1 email;internet:[EMAIL PROTECTED] title:Java Consultant fn:Marcus Ahnve end:vcard
