There are several options for database access where legacy database schemas are too complex for ActiveRecord to handle. The first is a mature ORM called Lafcadio. One of its design goals is to offer strong support for legacy schemas. Another option is to fall back from ORMs to direct database connections. Ruby includes a database abstraction layer called DBI, which is similar to JDBC in Java, and allows for database independence. Of course, another option would be to use a database driver directly. Note that ActiveRecord provides access to these other layers, so variations from ActiveRecord's preferred style of schema design can be handled without losing ActiveRecord's benefits.

Note that for working with Rails, the presentation tier doesn't require either ActiveRecord or any database for that matter. Rails can easily be used as a front-end to a Service Oriented Architecture (SOA) or any external service-based API that Ruby can connect to. In this tiered approach, there's a clean separation between the Rails presentation layer and the service and data layers. Different teams can develop the different layers using different technologies.

Ruby offers a number of options for integration with enterprise services. Ruby can be bridged to existing JMS messaging systems that support STOMP (the Streaming Text Orientated Messaging Protocol). STOMP is an open messaging protocol that provides publish/subscribe services, as well as receipt and transaction services. Ruby has good SOAP support, and Ruby classes can be generated from WSDL. It also has a very complete XML-RPC library.

Ruby has excellent base HTTP client support for custom HTTP messaging integration. It offers a WEBrick embedded Web server/servlet container for message exchange. WEBrick can also be easily integrated with existing CGI scripts and provides HTTPS/SSL support.

There are several areas where direct Ruby support for enterprise technologies is lacking. There's no standard Ruby service comparable to JMX for application management. There's also no support for a standard authentication/authorization service. Distributed transactions aren't available through any Ruby transaction manager. There's also no real CORBA support in Ruby. Finally, internationalization support isn't unified like it is in Java. Although there are libraries available to bridge some of the gaps, custom i18n development may be required, depending on the application.

In these areas where Ruby lacks native integration support, there are Ruby-Java bridges available for direct integration with existing Java code, or for bridging to services that Java's better at.

MomentumSI Recommendations
It can be a challenge to decide whether Ruby makes sense for a particular enterprise project. MomentumSI offers guidance on using Ruby on projects according to various enterprise application categories:

• Mission critical/non-stop processing: Ruby's not ready for an environment that includes integrating with transaction monitors or CICS/IMS interfaces.
• Complex transactional: Ruby's suitability in a complex transactional environment depends on the nature of the transactions. While Ruby doesn't offer native XA support natively, it can be integrated into transactional messaging systems. This opens up the possibility of using Ruby for enterprise application integration.
• SOA/Web Services: Ruby can be used as both a producer and a consumer of SOAP-based Web Services, enabling it to be used in Service Oriented Architectures.
• Data-intensive: Ruby has been proven in data-intensive applications. Examples include space shuttle simulations done by NASA and meteorological number crunching done by NOAA.
• Web applications: Ruby on Rails is a productivity leader in database-backed Web applications. It scales well and has excellent developer support.
• Workgroup software: Software in the enterprise targeted at workgroups usually requires rapid prototyping, which is a Ruby strength.