ROR supports Enterprise Application?

Hi All,

People are talking that ROR is not suitable for enterprise application.

Iam not sure what are all the qualified features for the enterprise
application.
If you know, plz post.

Also share your view on ROR supports enterprise application or not.

Thanks.

I believe the core issues with enterprise apps are security,
scalability & ability to support large numbers of concurrent users.

I am knowledgeable enough to debate for either sides yet on whether
ROR is enterprise ready.

RoR is far too easy, elegant and fast to develop with for it to be
ready for enterprise. Now if they can just find a way to make it big,
complicated, and no fun then it will be ready. But, wait that exists
already. It's called Java EE.

It is too easy for some to say "Rails is not suited" and it is equally easy to have a good comeback.
But to be credible lets start by listing the "enterprisey" features and show that Rails can handle
it.

I agree that no framework is fully ready out-of-the-box and new challenges can be overcome with
further development.

So let's start listing the "enterprisey" features ...

- Transaction support

-- Long
http://FATdrive.tv/wall/trakb/10-Long
http://FATdrive.tv/

Oops, I mean't:

*I am not knowledgeable enough to debate for either sides yet on
whether
ROR is enterprise ready.

This question seems to come up about once a week, it seems.

Am I the only one on this list who thinks that this question is
ridiculous?

This question seems to come up about once a week, it seems.

Am I the only one on this list who thinks that this question is
ridiculous?

no, you're not
i hope, ROR is not enterprise ready, since this would only bring in the
suits :wink:

Thorsten Mueller wrote:

This question seems to come up about once a week, it seems.

Am I the only one on this list who thinks that this question is
ridiculous?

no, you're not
i hope, ROR is not enterprise ready, since this would only bring in the
suits :wink:

I don't want to start a war, but personally, I am afraid that ROR
architecture may still be far from Enterprise applications. The most
obvious obstacles are coupling and scalability. For example, in
enterprise applications, domain objects should not be tied to database
schema and be long live objects. But they are in ROR right now. Also, it
is really bad for the web talks directly to database, which is not
security and not scalable either. For Enterprise application, usually,
the data services and web applications are separated. In this way, web
applications can be even written in different languages. For example,
our company data services are implemented in Java and web applications
are in both Java and .Net. The web applications never talk directly to
database. SOA is a bit further, services are sitting behind ESB and the
WSDLs are the main contracts, which should not be changed very often. If
you have 20 applications, as long as the WSDLs are not changed, the web
applications not need to be changed once the database schema is changed.

I'm sorry, but because this question *does* come up so frequently, it tests my patience. If you hear a loud "snap" that was my patience giving way. If what I'm about to say is offensive, I apologize in advance. It is more a rant about the question in general than this particular one.

<rant>
So the grand notion is that the more middleware you write the *better* your security story? That shipping data packets in fragile SOAP envelopes somehow imparts a loose coupling that will create more robustness? That adding more network traffic by decoupling service layers *improves* scalability? That somehow you got your API perfect in your WSDL but can't settle on a stable database schema? Call me old fashioned (and I *am* old fashioned, having implemented everything from enterprise payroll and shipping systems for Fortune 500 companies all the way through shrink wrap and back through a rabbit hole and out to Web apps), but I think "enterprise" is a word used in the software industry to mean needlessly complex.

I've seen far too many enterprise applications designed for over a year, built with the maximum amount of flexibility, security, and robustness in mind, only to discover half way through implementation that the problem domain had shifted and the wildly expensive project was irrelevant.

You go ahead and use waterfall method project methodologies. Design by committee and make absolutely sure you write the largest number of lines of code you can to solve the problem. We wouldn't want to think that your code is coupled too tightly to your problem domain. If "enterprise" means using tools created to solve problems in the 80s and 90s, then by all means, ignore the newfangled tools. But if you already knew that, why ask?
</rant>

Again, sorry for the rant.

I've found a number of gotchas when using Rails with Oracle, but I
haven't found any real show-stoppers.

I realize that my previous post was a sort of smart-ass remark, and
I'm sure many think it came from someone who has never stepped foot
inside an "enterprise" application. However, my day job is squarely
linked (think ball-and-chain) to the enterprise.

We do Java EE applications using Oracle JDeveloper. This is not what I
signed up for, however, one must go with the flow sometimes. So my
earlier remark was made purely from frustration. Example: Today I
needed to interface to a SOAP web service, so I used the built-in
generator provided by JDeveloper to create the web service proxy.
After running the generator I then committed the resulting
files....ALL 98 of them. Yep you heard right, 98 files to support one
stinking web service. If that's the definition of "enterprise" I look
forward to the day I am able to escape.

So I feel the same way about Rails and the enterprise as I feel about
the Mac and the enterprise. Neither of which, IMHO, should care
anything about the enterprise. It's not a target worth worrying about.
All you will find there is frustration and waste.

I don't want to start a war, but personally, I am afraid that ROR

architecture may still be far from Enterprise applications. The most
obvious obstacles are coupling and scalability. For example, in
enterprise applications, domain objects should not be tied to database
schema and be long live objects. But they are in ROR right now. Also,
it
is really bad for the web talks directly to database, which is not
security and not scalable either. For Enterprise application, usually,
the data services and web applications are separated. In this way, web
applications can be even written in different languages. For example,
our company data services are implemented in Java and web applications
are in both Java and .Net. The web applications never talk directly to
database. SOA is a bit further, services are sitting behind ESB and
the
WSDLs are the main contracts, which should not be changed very often.
If
you have 20 applications, as long as the WSDLs are not changed, the
web
applications not need to be changed once the database schema is
changed.

Ummm... use the model and activerecord to ensure the security of your
data? I'm not sure what the crazy worry is here. If you're afraid of
something like someone seeing the database password, then go crazy
make a second RoR program just to interact with the database and keep
it locked up wherever you store your .NET program.

Why on the world would anyone think its better to write in TWO
different programming languages for the same project is beyond me.

I have to agree with those who are fed up with this question. I was a
Microsoft .NET developer working in a consulting firm before 'getting
on the rails' so to speak, and I have to say that the term enterprise
is thrown around far too often. If you are being questioned whether
the product is enterprise ready your next question should be "What are
the requirements?" I have seen a tech support ticketing application
labeled as Enterprise, or a Vactation Request form labeled as
Enterprise. Both of these could have easily been done in almost any
language and had the same results. The question is not whether Rails
can handle the Enterprise, but rather whether the Enterprise is ready
for Rails.

Rails will demand a different programming skillset than say .NET.
Also, The Agile development methodology will mean big changes for most
teams, and Agile doesn't mean... many meetings a day to make many
changes!

It always comes down to the competency of the developers on a project.
You could have hard-core ColdFusion developers blow the socks off a
weak group of Java developers... I feel that the tools nowdays are no
longer a barrier to the style of application. Its far too often
becoming religion. I once sat beside someone who asked what I did, and
when said I was a Rails Developer he responded "Oh, I have heard that
is not as powerful as .NET because its scripted".

I think the philosophy that is lost on most development teams is that
less is more. To anyone that says Rails is not Enterprise Ready then
prove it. What requirement is not met? And if it is, that is not a
failure of Rails in the Enterprise, that's a failure on THAT
requirement.

Choose the tool that gets the job done and that your team has the
skills for, and learn to prototype! It will save countless hours and
dollars if you can prove/disprove a solution will work in the first
place... this is the answer to your original question. Try to figure
out why Rails won't work. It will be a much shorter list and possibly
no list at all. When the religious types show up... Java, .NET,
whatever... don't give their opinion much value unless they have a
specific example to share.

http://matthewcarriere.com

Rails supports building 20-50 table mostly-CRUD web applications (not
surprisingly, that's what it was created for). There is a huge number
of apps that fall right into this sweet spot in any corporate IT
environment.

For more complex domains, ActiveRecord pattern does have its
drawbacks. Tight coupling between domain and database makes your unit
tests either slow, or heavily mocked out, and therefore, expensive to
maintain. But you don't *have* to use ActiveRecord with Rails. There
is a number of "real ORM" persistence solutions in the works, and
ActionPack is still a wonderful technology to build web front-ends to
pretty much any kind of a service layer.

And then, there is JRuby, which happily runs on those pesky J2EE
containers, and let's you mix Ruby layers with Java layers at will, if
that rocks your boat.

People have done many "enterprise" projects with Rails, and even more
with Ruby. For any definition of "enterprise", including non-trivial
financial domains. In most cases, it was a pleasant, rewarding
experience for those involved. You just have to pick the right kind of
a project.