Hi, I don't see any "complexity of EJBs (in EJB 2)" in case if you are using just JMS/Session beans - Entity beans are really awful
2008/2/5, Renat Zubairov <[EMAIL PROTECTED]>: > Hi Angelo, > > I was just thinking how can you organize your application in case you would > use the EJBs: > > You will most probably use the Session Facade design pattern ( > http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html) > to provide the backend for your web apps that will be shared part across all > of them. For that you need to create one or many session beans. It's natural > that you will not be very happy about complexity of EJBs (in EJB 2) and/or > about immature dependency injection (in EJB 3) therefore you would most > probably use them only as facade and call some other dependency injection > solution behind them. Most probable candidate is Spring, however I'm pretty > sure you can adjust T5 IOC to be usefull on the backend side as well. > > Since EJB structure is very similar to the typical DI requirements (required > interfaces) you can easily create a service provider of some kind that will > automagically lookup the EJBs in the JNDI and inject them into your > pages/services wherever they are needed. > > I would also suggest you to keep the user dependent state on the web tier > and use when possible stateless components on the backend. > > All in all it seems that resulting structure might become complicated very > fast :( and also there is a big question wherever T5 IOC is really suitable > for the backend/EJB like operation (for example perthread lifecycle only > works when servlet filter is there). Also you need to take into account > Java5/JEE5 support is not very mature and you would have only limited choise > of containers in this case. > > Renat > > > On 04/02/2008, Angelo Chen <[EMAIL PROTECTED]> wrote: > > > > > > Hi Renat, > > > > I think your recommendation of j2ee and ear deployment is a better option, > > i > > think again, there is really no need to make the multiple module looks > > like > > one, we can have multiple web applications, now this T5 IOC inside EJB > > part > > without EJB is interesting, what's the advantage of this approach compared > > to using ejb? another thing is, T5 does not have direct support of ejb3 > > annotation. > > > > Thanks, > > Angelo > > > > > > Renat Zubairov wrote: > > > > > > Hi Angelo, > > > > > > Basically if you have a number of web application, Tap or not Tap :) > > there > > > are number of problems you need to solve if you want them to look as one > > > application for the user: > > > > > > 1. Authentication - in case you would use propreitary authentication > > > schemes > > > that are based on the HTTP sessions you might have some problems because > > > session would be different for different web applications therefore you > > > might need to integrate with the container managed authentication. > > > > > > 2. Persistence - as you mentioned in your first email "all modules > > should > > > share the same persistence store" since two different web application > > > can't > > > have common classes loaded at the same time (due to the fact that in > > > Servlet > > > container all WebApps are having it's own private classloader) you might > > > use > > > the same persistence module (a JAR file in the WEB-INF/lib) but in this > > > case > > > each web application would work with it's own Session (hibernate > > or JDBC > > > session). > > > > > > 3. Linking - since each web application will be deployed under different > > > context (http://your-domain.com/context1 and http://your-domain/context2 > > ) > > > you would need to consider how many links would you need between these > > two > > > and how to manage them efficiently (imagine context name changed?). > > > > > > Basically my recommendation would be - do it inside single web app :) > > you > > > will really have less problems! > > > > > > In case it's not possible I would suggest to leverage all J2EE parts of > > > the > > > container, such as JAAS and container managed authentication for > > > simplifying > > > multi-app authentication, JNDI and connection pooling for providing > > single > > > DB connection pool for multiple applications. > > > In case you are planning to deploy to a J2EE container you can benefit > > > from > > > J2EE deployment if you would put common parts of your application inside > > > EJB > > > JAR and all your WAR's inside one single EAR, in this case you can > > benefit > > > from the hierarchical classloading. In the end you can off course use T5 > > > IOC > > > instead of spring inside your EJB part without really doing any EJBs at > > > all. > > > IMHO it should be possible to automatically deploy all T5 services > > inside > > > the JNDI and then look them up in the Web Applications. > > > > > > Renat > > > > > > > > > On 04/02/2008, Angelo Chen <[EMAIL PROTECTED]> wrote: > > >> > > >> > > >> Hi Renat, > > >> > > >> EJB is not a must, any suggestions for this kind of app as long as > > front > > >> end > > >> is Tapestry 5. > > >> > > >> > > >> Renat Zubairov wrote: > > >> > > > >> > Hello Angelo, > > >> > > > >> > Main question is do you want to use EJB in your app or not, because > > >> > usually > > >> > there is no proper way to share state between multiple WAR's deployed > > >> > inside > > >> > the application container. > > >> > > > >> > Renat > > >> > > > >> > > > >> > > > >> > > >> -- > > >> View this message in context: > > >> > > http://www.nabble.com/T5%3A-best-practice-for-a-multiple-module-app-tp15260841p15263775.html > > >> Sent from the Tapestry - User mailing list archive at Nabble.com. > > >> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >> > > > > > > > > > -- > > > Best regards, > > > Renat Zubairov > > > > > > > > > > -- > > View this message in context: > > http://www.nabble.com/T5%3A-best-practice-for-a-multiple-module-app-tp15260841p15268374.html > > Sent from the Tapestry - User mailing list archive at Nabble.com. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Best regards, > Renat Zubairov > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
