On Tue, Dec 05, 2000 at 04:29:06PM -0800, brian moseley wrote:
> consider a scenario in which somebody uses a web interface
> to signal an action, which is placed into a message queue.
> on the other end of that queue, a service handles the event
> with a transaction that spans multiple third tier systems.
wouldnt such a system be better off hand-crafted with an RDBMS and nicely
laid out perl modules? why would you want to get stuck with a proprietary
application framework for such a case? technically/programmatically there
is not much invloved in doing something like this. its more of a design
issue than a programming issue. the Java based transaction
servers may have been designed and architected with good extensibility,
but i tend to feel that a hand-crafted system is going to be more robust
and extensible. i have had first-hand experience with so-called
enterprise tools from HP OpenView and they have miserably failed to meet
our requirements time and again. the Java based transaction monitors may
be better, but i remain skeptical..
> this is the kind of architecture that is begging to be
> embraced by perl.
absolutely. but that would be similar to making the same mistake that
companies like CommerceOne and Ariba are making: namely, portending to
build a piece of software that will satisfy the business needs from
companies in different business-verticals.
the gist of my argument is that systems like these just do not lend
themselves very easily to the diverse web-app-infrastructure that
enterprises will want to deploy.
ajit
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
