Originally posted by Niels Bech Nielsen: No matter how fancy and easy the interface might be developed (using RoR), enterprises needs to work with JTA and COM+ transactions, and perhaps even other distributed resources.
It's true that ActiveRecord's transactions support is lacking when it comes to distributed transactions. In that sense, Rails is probably not your first choice for a system that needs to interoperate with multiple transactional resources.
Having said that, it might not be the worst idea to encapsulate those distributed transactions behind a separate web service, for example, implemented with suitable technologies such as J2EE.
Such an approach would of course lead to the co-existence that you refer to here:
Originally posted by Niels Bech Nielsen: Is there enough integration between ruby and java for concurrent interaction in enterprises or will they try to co-exist (and hence one or the other or both becomes legacy at time).
...and that might not be such a bad idea either. I can't think of a single "enterprise" I've seen that wouldn't have multiple technology platforms in use or that weren't in the middle of some kind of a migration from one technology to another.
(By the way, I'm not sure what you mean by "concurrent interaction"?)
Originally posted by Niels Bech Nielsen: Have anybody seen anything showcased in Ruby which were not RoR or DSL or command line. (Application clients that is :-)
I for one haven't seen a single desktop GUI implemented in Ruby.
PS. I don't think it's appropriate to talk about "maturity" as if it would mean "supports distributed transactions and other enterprisey stuff." Rails is targeted at a different problem than J2EE, although there's enough overlap between those problem domains to occasionally create a real choice between the two technologies.
Ruby itself is over ten years old, and has a large standard library. We have used Ruby, for example, to:
1) authenticate users against, and pull data from, an LDAP store 2) drive existing COM/COM+ components through the Win32 integration 3) drive existing Java code through JRuby 4) communicate with JMS via STOMP 5) drive a distributed worker process system through Rinda and DRb 6) communicate directly with Perforce for file management
Originally posted by Pradip Bhat: Will Ruby support distributed transaction in future.
Who knows... However, "Ruby" supporting distributed transactions means that the following needs to happen: 1) Someone implements an XA-compliant Transaction Manager 2) Someone implements XA-support into Resource Managers for MySQL, PostgreSQL, etc.
I don't know the status of either these things--whether someone is working on them or whether they're perhaps done already.