Hi Leon, Spring: Well, our app started as a single jvm version and I used Spring (and will continue to do so) because it's an incredibly powerful, easy to use yet unobtrusive framework. You get transaction support, aop, hibernate/ibatis and support and DI by simply declaring it in your config file. And the best thing - it actually works - right from the start.
Apart from that, I don't know anything about Corba and I do NOT think that my boss would approve if I switched to a technology that none of our developers has ever used, especially since we're getting close to the deadline for our project. :o) Is RMI performance really that poor? I mean compared to SOAP it still should be much faster, right? What kind of performance hit are we actually talking about? Do you have any numbers for Corba/RMI/SOAP ? Regards, Tom Leon Rosenberg wrote: > On 3/29/06, Tom Ziemer <[EMAIL PROTECTED]> wrote: >> Hi Leon, > > Hi, > >> I've been doing a bit of reading and I guess I'll be using Spring's >> remoting support in conjunction with RMI. Seems like the easiest way to >> do this. > > If performance is not an issue, got for it. It's quite a pity that > people abandon well thought, highly supported industry standarts in > favor of proprietary protocols, but its another battlefield. Just > interesting, what were your reasons to prefer spring to corba? > >> Just out of curiosity, why did you rate EJB with a -10, yet RMI with a >> 0? AFAIK, EJB use RMI - so why do you consider plain RMI to be that much >> better? > > Per default EJB Containers have to use GIOP/IIOP -> corba. I consider > EJB (<3.0) for bad (there are a lot of books on this topic) since it's > a very heavyweight technology. -10 for EJB is not for remoting with > EJB, but the EJB itself (again <3.0, I haven't had much practice with > the new spec yet). > > RMI itself is pretty easy to learn and to use, and as long as you want > to stick with it, and don't need performance, it's ok. > >> Regards, >> Tom > > Leon > >> Leon Rosenberg wrote: >>> JMS as far as I now is comparable with the notification service in >>> corba. Therefore it offers you about 5% of the functionality corba >>> offers you. >>> >>> regards >>> leon >>> >>> Btw, JMS doesn't fit in ANY application, you should have the special >>> type of application to use it. >>> >>> On 3/28/06, Tom Ziemer <[EMAIL PROTECTED]> wrote: >>>> 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] >>>> >>>> >>> --------------------------------------------------------------------- >>> 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]
