[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dist-obj] Why use Application Servers?


Kevin Dick wrote:
>I believe Persistenhce also has a framework for
> updating the cache in the face of outside 
> database updates based on triggers and TIB/Rendezvous.

Yes they do.  It is called cache synch.  Check out the
INSTINET case study  at:

http://www.persistence.com

It really blows away most other EJB implementations as
far as being able to connect multiple app server clusters
and making them work together.  As far as a transaction
service I still prefer BEA's, but that's another thread.

The INSTINET case study and other similar implementations 
by Persistence in the works, (we have been involved in
a few implementations), have thousands of EJB app servers 
working together in a global network (Tokyo, NY and London 
I believe).

In fact, last time I checked the SUN's EJB site a few
weeks ago, the INSTINET case study was still the only one 
featured.

But I think Persistence's cache synch is actually more 
than just a component bus.

What's going on is that the cache synch acts as a
rule-based large-grained component bus.  Think of your 
typical component + component bus + messaging service 
implementations:

	Java Beans + Java Event Mechanism
	Components + MTS (DTC) + MSMQ
	Beans + EJB + JTS + JMS
	Jinis + Transaction Service + Messaging Service

The typical bus doesn't bundle "component state synch rules", 
...but in Persistence you can just "listen" at just the cache 
state changes that you want out of the box.  

Yes, I know, someone can argue that "it really shouldn't 
be that hard to build a rule engine on top of any messaging 
scheme by filtering events through rules, that have attached 
actions, and that synch portions of a cache blah, blah, blah...  
But most people often get confused in their choices at that point.
(Compare the above with your typical MTS behavior out of
the box... :-)

The nice thing is that Persistence forces you into that
multi-paradigm programming structure, offering a declarative
interface at the highest level of abstraction.
(No Philip, don't worry, I won't start yet another 
"functional is better at a high level of abstraction" 
thread here :-)

In that sense, it offers the kind of multi-paradigm
programming environment that I often talk about ... 
mixed logical, functional and imperative modes combined 
at different levels of abstraction to better fill the 
needs of an architecture.

- Mike

__________________________________________________________________
 Mike Beedle
 Principal
 e-Architects Inc.
 beedlem@e-architects.com
 http://www.e-architects.com



==========================================================================
To manage your subscription, mailto:dist-obj-help@distributedcoalition.org 
Archives, FAQ, etc.     http://www.distributedcoalition.org/mailing_lists/