Hi Leon, 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.
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? Regards, Tom 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]
