struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Ziemer <t.zie...@dkfz-heidelberg.de>
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.

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 <szabtam@gmail.com> wrote:
>> Hi Tom!
>>
>>
>> On 3/28/06, Tom Ziemer <t.ziemer@dkfz-heidelberg.de> 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 <t.ziemer@dkfz-heidelberg.de> 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 <t.ziemer@dkfz-heidelberg.de> 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: user-unsubscribe@struts.apache.org
>>>>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message