> You could have a single box with.
> 1) JRun
> 2) One or more CFMX Server instances
> 3) JMS server (JRun built-in or another)
Yes, true, you could.
> Being able to do this (decouple the data input from the data
> processing) will allow the CF Developer to address a larger part of the
> total application needs of the enterprise.
Yup, this is exactly what we're doing here at Macromedia. In the past,
such decoupling required either using a common database or passing
flat files around. Both of those have their downsides and both also
cause the hand-shaking / persistence mechanism to 'bleed' into the
applications.
By using JMS messaging, you can seamlessly add and remove subscribers
without affecting the publisher (and vice versa). We have several
situations where we publish a message to the hub, oblivious to how
many subscribers there are - and we can add additional subscribers to
get data into new systems as and when we need. That decoupling is very
powerful.
> In a way, it is analogous to an internal-use-only web service -- with
> the additional advantage that the service doesn't need to be available
> for me to request (and be assured that I will receive) services.
Yup. And the choice of web service vs messaging for us depends
entirely on whether we need a transactional response (web service) or
not (messaging). That in turn determines how "available" each 'end' of
the data exchange needs to be...
--
Sean A Corfield -- http://www.corfield.org/blog/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
