Hi Leon, thanks for the input. May I ask how you would rate JMS and if this would also be a suitable solution for decoupling applications? I am a bit reluctant to switch to CORBA since I have absolutely no experience in this area.
Regards, Tom Leon Rosenberg wrote: > If you want performance go for CORBA > if you want interface stability go for CORBA > If you want simplicity go for RMI > > If you want use 3rd party products go for EJB (CORBA would do also). > > In my personal opinion, EJB would be a -10, SOAP -5, RMI 0, CORBA +1. > > If you are looking for a good (or best) corba implementation (orb) : > www.jacorb.org > > regards > Leon > > On 3/28/06, Tamas Szabo <[EMAIL PROTECTED]> wrote: >> Hi Tom! >> >> >> On 3/28/06, Tom Ziemer <[EMAIL PROTECTED]> wrote: >>> 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. >> >> Hibernate has pluggable caching. So you can use distributed caching if that >> is the only >> concern that you have. For example check out SwarmCache or just google on >> Hibernate distributed caching. >> >> However, I haven't used it cause we haven't used caching (Hibernate didn't >> had exclusive access to the database) >> >> By the way if you decide to go for more JVMs, I would probably use RMI. I >> would also have a look at Spring's support for remoting because I think you >> can expose your managed beans easily. >> >> I wouldn't use SOAP, it's big strength is that is HTTP based so it can be >> used by the majority of the clients (isn't blocked by firewalls). >> And I would choose RMI over CORBA if there are only Java applications >> involved. >> >> This is only my preference list of course try to get as much oppinions as >> you can ;-) >> >> >> Tamas >> >> >> >> 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] >>> >>> >> > > --------------------------------------------------------------------- > 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]
