Hi Tamas! Unfortunately, I cannot include my base-jar in both projects, because I am using Hibernate, which heavily uses caching. Therefore, updates that are performed by web services are not visible on the web. Having two versions of a hibernate app accessing the same db is not a good thing to do (concurrency!). This is exactly the issue that made me look at JMS/SOAP/RMI/etc. If you have any idea, how to circumvent this problem, I'd be more that happy to stick with the single-JVM-approach.
Regards, Tom Tamas Szabo wrote: > Hi Tom, > > Is there a reason you can't have all the business service layer in a Common > project and include it as a jar in both the web gui an the web services app? > I usually use this approach if possible... > > I'm interested in what others say about this but I wouldn't go on the path > you want to go if it is avoidable. > > Tamas > > On 3/28/06, Tom Ziemer <[EMAIL PROTECTED]> wrote: >> Hi Tamas, >> >> thanks for your reply. Modularity is not my only concern. I am pretty >> sure that performance considerations will soon force me to separate the >> app, since the web services will do lots of number crunching, which in >> turn, will slow down the entire app. Apart from that, I figured it's a >> better, cleaner approach plus it's gonna me more stable (I hope), since >> e.g. if the web services "break" the web gui will not be affected in any >> way. >> >> Regards, >> Tom >> >> Tamas Szabo wrote: >>> HI, >>> >>> Do I understand it correctly? >>> Do you want to break it up just to ensure that is modular? >>> >>> If it isn't a requirement then I wouldn't add some communication layer >>> between the modules. >>> Be happy that you have everything in one JVM and you don't have to deal >> with >>> the complexity resulting from ANY of the technologies you mentioned. >>> >>> Just my 2 cents, >>> >>> Tamas >>> >>> >>> >>> On 3/28/06, Tom Ziemer <[EMAIL PROTECTED]> wrote: >>>> Hi, >>>> >>>> I am a developer, currently working working on a medium scale app. >> There >>>> is a base module, which is Spring managed, that handles data access - a >>>> web tier and now a couple of web services. Up until now, we deployed >>>> everything as one application, so communication between the modules was >>>> API-based and thus not really an issue. Now I am wondering, whether it >>>> is prudent to deploy each module separately and add a communication >> layer. >>>> So my question is, whether or not it is sensible to break the app apart >>>> (for the sake of modularity) and if so, how the individual components >>>> should communicate with each other. >>>> >>>> - Most of my requests to the business layer will be synchronous, so I >> am >>>> not sure whether JMS is the right technology to apply. >>>> >>>> - RMI would result in a very tight coupling and I'd be restricted to >>>> using JAVA everywhere. >>>> >>>> - CORBA - haven't used it yet. >>>> >>>> - SOAP - great when interoperability is an requirement, lots of >> overhead >>>> (XML). >>>> >>>> I am not trying to start a rant about which technology is better - I am >>>> simply looking for the best solution for my problem. Surely, many of >> you >>>> had to make a similar decision at one point or another, so I'd be >>>> grateful if you would share your experiences and/or advise on how I >>>> should proceed. >>>> >>>> Regards, >>>> Tom >>>> >>>> --------------------------------------------------------------------- >>>> 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]
