Yes, I suggest to you the same approach. Put everything in the same webapp, just take care to separate the tiers.
For example: don't modify inside a service method the method parameters because it won't work in a EJB for example. I used to build a huge environment n-tier with different jar files for each tier, beautiful from the architecture view, but expensive to develop, and sometimes you don't need this huge approach. My advice is, do it simple but taking care to handle evolution, to in the future put it a cluster, ejbs, jms, etc. The architecture that I use is: Wicket in front end, components calling service methods. Service methods using JPA/Hibernate and now I will use Warp-persistent Dynamic Filters to act as a DAO. I always use DTO in service methods. My point of view is that if you have a method named "getSimpleUserList" and your User entity has 10 attributes and for this simple list you just need 3 of them, doesn't make sense to me return a Set of User objects, for that I would create a SimpleUserDto and return a Set of it. Please, if I was confuse, ask me more, my english isn't perfect. Thanks On Tue, Mar 24, 2009 at 12:41 PM, James Carman <[email protected]> wrote: > Put your services in the same webapp. > > On Tue, Mar 24, 2009 at 11:37 AM, Kaspar Fischer <[email protected]> wrote: >> I am trying to figure out the architecture of a prototype application. In >> it, the presentation layer (Wicket) needs to work with a service layer to >> display and edit lists (among other things). The service layer also exposes >> some Web Services via SOAP/REST which I intend to use for a Flash/Flex >> component that will be on the pages served by Wicket and will display the >> lists in a graphical and interactive way. >> >> What options do I have to connect the presentation and middle layer? >> >> - RMI between Wicket and the service layer: This would allow them to run >> separately (e.g., we can work on the presentation without taking down the >> service layer who is running background processes). >> >> - Service layer and Wicket in the same webapp. >> >> - Service layer and Wicket in separate webapps but with Tomcat's >> crossContext set to true. >> >> - Anything else? >> >> Can anybody share some recommendations or experiences? >> >> I am worried that RMI will not only be a performance bottleneck (is it?) but >> also that it will be hard to work with models. Looking at wicket-phonebook, >> >> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/phonebook/src/main/java/wicket/contrib/phonebook/web/DetachableContactModel.java >> >> I see that the presentation layer has access to the DAO and stores id's in >> its models. With an RMI separation, the DAO is in the middle layer and not >> accessible from the presentation layer. Also, transactional boundaries are >> in the service layer, so I will not be able to do something "more complex" >> in the presentation layer (which I shouldn't do anyway, I guess). >> >> Many thanks for feedback, >> Kaspar >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
