[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dist-obj] Why use Application Servers?
- To: "Dist-Obj Mailing List" <firstname.lastname@example.org>
- Subject: Re: [dist-obj] Why use Application Servers?
- From: "Mike Beedle" <email@example.com>
- Date: Thu, 23 Mar 2000 03:05:35 -0600
- Delivered-To: firstname.lastname@example.org
- Delivered-To: mailing list email@example.com
- Delivered-To: moderator for firstname.lastname@example.org
- Importance: Normal
- Mailing-List: contact email@example.com; run by ezmlm
- Reply-To: <firstname.lastname@example.org>
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:
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
In fact, last time I checked the SUN's EJB site a few
weeks ago, the INSTINET case study was still the only one
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
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.
To manage your subscription, mailto:email@example.com
Archives, FAQ, etc. http://www.distributedcoalition.org/mailing_lists/