Enterprise-Ruby Wish List

In all the recent talk (some would say hype) about the Ruby programming language,relatively little has been said about Ruby's usefulness in enterprise development shops, but that is beginning to change.

Many have asked whether enterprise developers need a new language. This question rarely gets farther than "who needs anything but Java?" And when it does, the debate usually degenerates into vehemently opinionated arguments about Ruby's performance, language features (like dynamic typing, protected namespaces, native threading, etc.), and lack of a major corporate sponsor.

I'm going to sidestep that usual debate by turning the question around. What do enterprise developers need, that they're not getting from their tools today? Based on the answers to that question, we can look at whether Ruby currently has anything valuable to offer. And the place to start looking is in the software infrastructure that's needed to support complex enterprise applications.

Application messaging is all about interoperability and integration. In other words,"glue." The technical and security issues here are rather well understood, but for some reason this area has lacked full-featured and dependable open solutions. The presence of JMS as a de facto API-level standard has caused the available solutions (free and commercial) to be strongly Java-centric, which slows down the integration of more agile software components into enterprise networks. Another major problem is the rigidity created by traditional integration techniques, which makes message-based architectures difficult to use and to scale.

A competent Ruby-based message-queueing system based on the most recent standards and security practices can fill the gaps in this picture. It would be particularly interesting to support the emerging AMQP protocol, which promises interoperabiility with new and established Java-based solutions. Agile development promises rapid and flexible solutions to business problems. An agile software-integration infrastructure is a major step toward realizing this vision.

Central Authentication/Authorization

There has been a lot of emphasis on Identity Management in the last several years, and most enterprises now have a competent approach to authentication.Authorization, however, has been left to the domain of individual applications, shoe-horned into authentication solutions, or both. And many smaller enterprises, which often do not run large "silo" applications apart from email, haven't really approached the authorization issue at all.

But the emerging "applications" which will provide much of the future value from IT investments often look more like ad-hoc vehicles for collaboration and information sharing than like traditional applications. And for these, the need for properly-managed access control is even more important and challenging. Especially since this new generation of information systems will generate tremendous value by extending your ability to touch your customers and partners, taking you right into the realm of federated access control. Many large enterprises wrongly view all of this as an application-integration challenge. Many small enterprises don't even see it coming.

None of this fits into the standard solutions for either authentication or authorization, in large enterprises or small. A centralized access-control infrastructure is needed, that is secure and auditable, but also highly scalable and easy to integrate with applications and with attribute servers like presence engines.

Some interesting academic work has been done in this area, but much remains to be done to bring the benefits to enterprises. This area is sensitive enough to require solid vendor offerings and support, but much of the required development and integration will benefit from Ruby's agility and flexibility.

Databases

Databases are basically fine the way they are, and Ruby is already well known for making it easy to integrate databases via functional interfaces rather than by exposing data models.

Web Development

Ruby has had some highly visible success in this area, with a product (Rails) that addresses an important problem domain (web applications with newly-developed data models and light integration requirements). It's not enough to say that Rails solves this problem. Rails *annihilates* the problem, and richly deserves its success.

But enterprises have considerably broader requirements in regard to "web development" (which is really to say, client-side development in general). Client-facing applications also need integration with existing databases, high performance and scalability, deployment flexibility, and the ability to work closely with other applications.

It's easy to see from the Java world, which has literally hundreds of different Web-development frameworks, that one size does not fit all in the world of client-application development. The Ruby world is already beginning to see some new approaches to client-development, with more to come. Frameworks similar to Java's Tapestry that are based on component models rather than on MVC will be particularly noteworthy. These will provide a totally different way to apply Ruby's agility and productivity benefits to the broader requirements of enterprise shops.

SOA

The SOA world faces substantial challenges today, after several years of hard work, and the road ahead is not clear. Vendors are driving a lot of controversy over standards and methodologies, which bogs down the process of delivering real value. I suspect that Ruby can bring agility and flexibility to SOA, but it's not clear yet exactly how.

Deployment Infrastructure

Java has been very successful indeed at providing manageable and dependable facilities for deploying large, critical applications and providing a wide range of runtime services to them. However, these infrastructures depend on extensive, rigid, and complex procedures for configuration and management. Therefore, it's often difficult to rapidly integrate new facilities and respond to changing requirements.

At the same time, agile software has been rightly criticized for finessing the critical issue of manageable deployment. Indeed this has been a key reason not to deploy Ruby applications in enterprises. For example, Ruby today provides not much more than manual processes for deploying an application to, let's say, a hundred production servers.

Ruby needs a comprehensive set of deployment facilities and runtime containers (supporting Inversion of Control and Dependency Injection patterns). These must provide a range of services to Ruby applications (including logging, messaging, persistence, access-control, eventing, and more) that can be managed and controlled by system administrators rather than programmers. Java has done well in this area, and has much to teach Ruby. But when the lessons have been learned, we'll have an agile application-management framework that will bring scalability and flexibility far beyond what is currently available, and may even transform the way that today's applications are deployed and managed.

Conclusion

Enterprise IT managers value application stability, manageability, and professional support. Programmer productivity barely makes the priority list. However, the business owners of IT value fast, comprehensive solutions to problems, and the ability to use information to grow the top line and the bottom line, and to improve customer service. The need to bridge these divergent priorities will create opportunities for Ruby in the enterprise.

Why do we need my Enterprise Ruby Wish List, when many of the pieces already exist as both free and commercial Java solutions? To reduce friction and costs, speed up solution delivery, and catalyze the behaviors that IT's business drivers demand.Java will be hard pressed to do this because it's become tightly-bound by established practices, methodologies, and traditions.

The pace of real innovation in the Java world has slowed, as important (but relatively minor) language improvements come to the fore, and much energy goes into creating incremental improvements to existing solutions, while major innovations like EEv3 see surprisingly slow uptake. At the same time, critical pieces of the application stack have been taken over by well-defended (and extremely expensive) commercial offerings. On the whole, the Java world is vendor-centric rather than community- or business-centric.

But does Ruby have what it takes to go beyond today's challenges and make a valuable contribution to enterprise IT? That's my next column.

So you are saying that we need a copy of J2EE? I cant see why. Its not the language that kills the developers in J2EE. Its the arhitecture that is just too complicated for most tasks and then there is a huge marketing force that pressures managers to include every possible tehnology in every project. For short, its the J2EE way of making complicated solutions for simple problems. I believe in using right tool for the job. Java, XML, SOA are not the solutions for every problem. Just like Ruby isnt. Though i have a feeling that ruby will replace many enterprisey solutions for simple problems.

I do not agree with the critia simple versus complex for choosing ruby or java as the development language. I believe the choice boils down too - from a language perspective - , does the problem domain require type safety, or not. Ruby would'nt be my primary choice for example for a accounting system of a medium to large enterprice. Java - especially since JDK 1.5 - would be more likely. Not so much a matter of preference, but avoiding a whole bunch of errors, which are a possibility in languages, which don't do type checking at compile time.That said, i really believe, that ruby very much has a room in the enterprise computing area, even for complex systems (...even more?) and also in combination with Java (JRuby).Therefore i really appreciate and agree with the Enterprise Ruby Wish List. From my perspective the IDE is one of the critical paths. You simply can't do any large scale development without the refactoring capabilites a Java IDE takes for granted now a days. Compare Eclipse Ruby Workbench by RubyPeople - which is great for a start - with the Java Workbench.....

I think the biggest needs are the ability to integrate into existing enterprise systems. This way Ruby can initiate in smaller projects, maybe integration glue and expande from there. To Chris above: I think the biggest reason why dynamic languages (like Ruby) are getting more popular now and have people thinking about using them in more ambitious ways has to do with agile development methodologies and the advent of writing developer tests. Regarding your accounting system, I guarantee that I could write a bunch of Java code that compiles, but it still riddled with bugs. The only way to have faith that the code is good is to have a rich test suite that can be run in JUnit. It's because of this desire now to have all these developer tests written that dynamic languages are gaining so much momentum (and why they can). Who cares what the compiler tells you...if you've written your test suite proberly, it'll let you know whether the code actually works or not, whether it's compiled or not. I'm sure in several more years, people will be saying...type safety? Bah.

It's not quite fair to compare Eclipse Ruby feature with Eclipse Java SDK. Refactoring features in Java and C# IDEs rely on the possibility to statically analyse the code. As far as I can see it is not possible to implement something equivalent for a dynamic language. I guess increasing popularity of Ruby, Python etc. calls for new types of IDE tools.

I don't agree at all. The J2EE architecture is complicated because the Java language doesn't have the meta programming facilities required to let framework developers, application developers and deployment/management staff work together in a consistent and productive manner. Ruby's meta programming features replace deployment descriptors, aspect oriented programming, byte-code post processing, all the dynamically typed expression languages (JSP-EL, etc) and a lot of other things.

Contrary to what you say, I think Ruby is nice to have for simple problems, but where it's really desparately needed is the the complex problems of enterprise development, and the even more complex problems of inter-enterprise integration.

Don't worry, Ruby is not going to be damaged if and when things like distributed transactions, messaging, SOA and proper unicode support are put in place.

I did not say that level of complication is the criteria, its too vague anyway. There are many others: size of your code, need for clustering and transactions etc.

I did say that there is no such thing as a simple j2ee solution. For example, even for most simple piece of software you must write a lot of xml(untestable and not checked at compile time). I have nothing against Java the language(ok, maybe i find it a bit boring) or against j2ee technologies, but i must admit i really dislike enterpricey attitude of killing flys with cannons. And i dont want that attitude in ruby community that is still fun and pragmatic.

But I agree with you on IDEs and JRuby+Java combination. And with Todd on the integration problem. I for one would like to have a JMS binding for Ruby.

And i wont touch the type safety flamebite. I dont think its relevant in this discussion.

Ruby as a language has arrived, but I guess support for type safety is as weak as in any other languages. Do we not need generics? The meta programming feature should give us an elegant generics implementation. Some of the available generics support looks complicated - unlike ruby.

Yes, lot of the things could be made simpler using rubys metaprogramming but many things in j2ee could be done simpler in java. But they just dont do it for some reason. They prefer configuration to convention.

I don't mean to be rude, but if you find it horrible that a list can contain 1 and "hello", then you should stick with BASIC. If you force items of arrays to have a common type, then you force interfaces on the language, and if you do that, you defeat the entire purpose of Ruby. Sorry.

Exactly how much serious Ruby code have you written? Before you critique the language, you might consider writing some serious code in it.

I develop strictly behind-the-firewall enterprise distributed software systems. My distributed applications are all heavily event driven and absolutely depend/require bi-directional (JMS) messaging. There is no web development - only .NET rich clients and embedded devices (which those are currently programmed via C# .NET Compact Framework) coupled to Java for the middle-tier. As such Ruby on Rails (and all web frameworks) are of zero interest to me.

I programmed in perl for several years and am keenly aware of how rapidly software can be developed in type permissive scripting languages.

So this article's first paragraph very much piqued my interest. I was keen to see if Ruby had anything to offer an enterprise developer in my shoes.

Alas, by the time I got to the end of the article I was very disappointed. The article indeed amounted to almost entirely a wish list for Ruby.

As things stand, I'm getting adequate scripting language utility out of Groovy. It runs on my JVM and integrates wonderfully with my Java software systems. Great for testing and prototyping. (I still use perl to craft any special build environment tool infrastructure.)

I admit Ruby is a cleaner language than perl (but perl has a ton of useful features that still set it apart and enable it with tremendous utility as a general purpose scripting language).

No doubt web jockeys have much to be excited about in regard to Ruby and to Rails. Yet for enterprise developers such as myself Ruby still remains pretty much a non event as there is just nothing new and useful that I don't already have access to with my current arsenel of tools/languages. Besides, Groovy has captured my attention much more so than Ruby (or JRuby). It has a lot more to offer to what I do programming-wise today.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.