Hello Leon,
Just wanted to mention that another decision factor is the available
pool of human resources ;-)
Manos
Leon Rosenberg wrote:
On 3/29/06, Tom Ziemer <[EMAIL PROTECTED]> wrote:
Hi Leon,
Hi,
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.
If performance is not an issue, got for it. It's quite a pity that
people abandon well thought, highly supported industry standarts in
favor of proprietary protocols, but its another battlefield. Just
interesting, what were your reasons to prefer spring to corba?
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?
Per default EJB Containers have to use GIOP/IIOP -> corba. I consider
EJB (<3.0) for bad (there are a lot of books on this topic) since it's
a very heavyweight technology. -10 for EJB is not for remoting with
EJB, but the EJB itself (again <3.0, I haven't had much practice with
the new spec yet).
RMI itself is pretty easy to learn and to use, and as long as you want
to stick with it, and don't need performance, it's ok.
Regards,
Tom
Leon
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]
---------------------------------------------------------------------
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]
