struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Ziemer <>
Subject Re: [OT] JMS, RMI, CORBA, SOAP or what?
Date Tue, 28 Mar 2006 14:46:07 GMT
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.


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) :
> regards
> Leon
> On 3/28/06, Tamas Szabo <> wrote:
>> Hi Tom!
>> On 3/28/06, Tom Ziemer <> 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 <> 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
>>>>> 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
>>>>>> 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 <> wrote:
>>>>>>> Hi,
>>>>>>> I am a developer, currently working working on a medium scale
>>>>> 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
>>> 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
>>>>>>> using JAVA everywhere.
>>>>>>> - CORBA - haven't used it yet.
>>>>>>> - SOAP - great when interoperability is an requirement, lots
>>>>> 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
>>>>>>> grateful if you would share your experiences and/or advise on
how I
>>>>>>> should proceed.
>>>>>>> Regards,
>>>>>>> Tom
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail:
>>>>>>> For additional commands, e-mail:
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message