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]
