struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanouil Batsis <>
Subject Re: [OT] JMS, RMI, CORBA, SOAP or what?
Date Tue, 28 Mar 2006 13:10:50 GMT

Hello Tom,

In short, there is no panacea or golden formula. I usually go for EJBs 
for my business logic (so, RMI & JMS). You can bypass RMI when on the 
same JVM by using local interfaces and in some servers AFAIK you dont 
even have to explicitly do that.

Personally, i try to avoid web services, especially the SOAP/WSDL crap 
but thats just me. REST might be good if you like it. I have seen 
several systems working perfectly for years with simple XML messaging 
(asynchronous or not) over HTTP; it's the implementation quality that 
matters here.



Tom Ziemer wrote:

>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
>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.
>To unsubscribe, e-mail:
>For additional commands, e-mail:

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

View raw message