[ http://issues.apache.org/jira/browse/DAYTRADER-23?page=comments#action_12451386 ] Christopher James Blythe commented on DAYTRADER-23: ---------------------------------------------------
David... I completely understand the reluctence... and you are right, this does add an additional degree of complexity. Nevertheless, I think we need to come up with something to address the following... - Better modularity and package organization - Ability to easily plugin additional backend implementations - Support EE4 technologies (and others) for comparisons Regardless of what we decide, I think #1 is an absolute must. I really hate how the ejb jar contains both EJB and JDBC impls and they are actually dependent upon one another in certain scenarios. Furthermore, I have always wished we could deploy Trade on Tomcat by itself without the EJB impl. As for #2 and #3, the real value in Daytrader and Trade has always been as a means of comparing performance, either for release to release measurement or for comparing technologies. Consequently, it would be nice to have an easily pluggable framework for managing different persistence impls (JDBC, EJB 2.1, JPA, EJB 3.0, Hibernate, Spring, etc.) . From a customers perspective, I would want to be able to use something like Daytrader to measure the performance of the stand JDBC mode and compare it to JPA and see where things shake out to determine what technology I use in the development of an application. In order to do this, I see two options... a) either build a pluggable framework or b) create multiple versions of DayTrader. Lets just say "b" scares me a lot more than "a". I guess before going any further and talking about the details, I should ask if anyone agrees/disagrees with the 3 basic goals I defined above? Chris > Decouple backend impls in order to support additional backend implmentations > (ie. JPA, EE5, etc) > ------------------------------------------------------------------------------------------------ > > Key: DAYTRADER-23 > URL: http://issues.apache.org/jira/browse/DAYTRADER-23 > Project: DayTrader > Issue Type: New Feature > Components: Web Tier, EJB Tier > Affects Versions: 2.0 > Reporter: Christopher James Blythe > > Currently, all of the backend impl modes (Direct, EJB and the new SLSB to > JDBC) are packaged together inside the ejb.jar. To provide greater > flexibility and the ability to support additional back impls, I think we need > to re-org the code within Daytrader. I've been brainstorming and have come up > with the following... > Create interfaces for the DaytraderServices and each of the access beans (ie. > QuoteDataBean, OrderDataBean, etc.) > util.jar (contains the following...) > - Interfaces for access beans - defines interfaces with getters and > setters > - DaytraderServices (interface) - defines the high level transactions > similar to TradeServices > - Operation return types are based on access bean interfaces > (not impls) > - Any other commonly used routines > For the EE4 component impls... > jdbc-impl.jar (depends on util.jar) > - Contains DaytraderJdbcServices class that implements > DaytraderServices interface > - Also contains impls for access beans that will be used for all EE4 > components > ejb2.1-impl.jar (depends on util.jar and jdbc-impl.jar) > - Contains 2 impls for EJB modes (Session2Jdbc and Session2Entity) > - DaytraderSession2JdbcServices class provides SLSB that > wrappers DaytraderJdbcServices > - DaytraderSession2EntityServices class provides SLSB to Enity > bean impl > - Both impls depend on access beans defined in jdbc-impl.jar > For the EE5/JPA components > - Define new access beans for EE5 impls based on interfaces > - Also create new impls for DaytraderServices interface > Provide DaytraderServicesFactory class which can... > - Detect which impls a present during initialization using > Class.forName() > - Create instances of the desired services given a string parameter > (assuming the service available) > - Can either be packaged in the war or another utility jar > - CANNOT go in util.jar to avoid circular dependency > Key points: > - New backend impls are isolated to their own jars > - Backend impl jars can be removed for AppServers lacking support > - Operation return types are based on interfaces (consequently EE4 and > EE5 impls could co-exist) > - war servlets and JSPs only know about access bean interfaces > Any thoughts or comments? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
