One of the clear goals for Rails from the start was to stay at the infrastructure layer. I didn't want Rails to succumb to the lure of high-level components like login systems, forums, content management, and the likes.
I worked in a J2EE shop for seven months that tried to pursue the component pipe dream for community tools with chats, user management, forums, calendars. The whole shebang. And I saw how poorly it adapted to different needs of the particular projects.
On the surface, the dream of components sounds great and cursory overviews of new projects also appear to be "a perfect fit". But they never are. Reuse is hard. Parameterized reuse is even harder. And in the end, you're left with all the complexity of a swiss army knife that does everything for no one at great cost and pain.
So Dan Creswell's SOA doomed? rings particularly true in my ears. And reaffirms my belief that Rails will do the right thing by resisting the temptation of high-level components and focus on bettering the infrastructure:
All attempts at creating high-level business components that can be re-used and re-configured have failed previously. This failure has not been for technical reasons - it happens because the requirements that yielded the original component interface were sufficiently different from the new requirements so as to require re-writing massive chunks of functionality.
I have similar issues with the ever recurrent case tool dreams. I'll address those some time.
I agree with you, 100%, David. Advocating component-oriented architectures so that you can reuse those high-level components in multiple projects *is* a pipe-dream.
However, there are other arguments for component-oriented architectures. Rails already uses the kind of components I'm talking about--"link_to", "text_field", "error_messages_on". Though simply methods, they are also components in the sense that they encapsulate the behavior (mostly the rendering) of some visual component of the page. They are also more general than the "forum" type components you mentioned--smaller, with fewer requirements and parameters. I think this is why they can be successful.
I certainly do NOT advocate Rails changing its underlying architecture to accomodate "true" (ie, Object-based) components. But that's because I think Rails can support these kinds of components as a layer on top of the existing architecture. Is this a valuable approach? Maybe, maybe not. I think it remains to be seen.
Perhaps this is all just a glorified science project. :) But I like science projects. And as we've seen with Routes, sometimes a science project can actually turn into a valuable addition to Rails, to even *your* surprise! :)
So, to summarize: I agree with you, David, that Rails' architecture is at least sufficient as it stands. I certainly do not advocate changing it. But experimenting with what can be done as third-party extensions to Rails might be fun, and perhaps even useful.
I've never worked with J2EE and I've only been using Ruby for about 6 months (I came from ugly PHP code), so take my input with a grain of salt.
I've really liked how the generators work so far. They give you a starting point with options to change it. The login generator for example has helped me out a lot so far. Out of the box it hasn't met my needs, but with a few minutes of reworking it's great. I'm not suggesting changing Rails in any way (please don't :-)) but I would like to see some more useful generators that give you a little push in the right direction.
I believe generators and starter-kits as suggested on the Rails list, can indeed help developers get things going fast.
Not as reusable black-box parameterized components, but as customizable template code.
This kind of thing works best if you keep it as simple and focused as possible, so developers can quickly get a grasp on it. (just like the login generator, as mentioned)
David, have you ever developed native desktop applications? Would you say that Cocoa for example does not work? Cocoa is about components and for me it has worked great many times! Perhaps it's a matter of granularity? I agree with you that, let's call it fat components, tend to be unsuccessfull. On the other side, lightweight components, or better call it "widgets", seems to work for many people. And Tapestry clearly shows that it _can_ be done for web developement as well.
Lars, I like that you mention Cocoa because two things I noticed in the linked-to article was:
“We have plenty of problems with re-use at the object/class level”
“it's about modelling things in a different way such that all the problems of changing requirements etc do not have substantial interface impact”
I think Cocoa has partially solved this by using the delegate pattern. I believe the same is also used in WebObjects, and one of the advantages of that was AFAIK that you didn't have to write (much) code, but just re-use existing components.
The problem probably is that to little emphasis is put on actually interfacing components with each other. Traditional OO is often used but rarely the answer for this IMHO.
Classes give a false sense of encapsulation and re-usability.
"Cocoa is about components and for me it has worked great many times! Perhaps it's a matter of granularity?"
The thing about a Cocoa app is that, for the most part, it has limited remote interaction. Just imagine trying to run a Cocoa app with each and every component accessed via some networking layer - it'd be dead slow. Thus SOA cannot use the level of granularity that Cocoa does because of it's remote access nature.
"The problem probably is that to little emphasis is put on actually interfacing components with each other. Traditional OO is often used but rarely the answer for this IMHO."
Maybe - delegation is certainly a better model for re-use than a lot of the others but I think the core issue is delegating the right elements. With a small component, it's reasonably easy to open up the internals via delegation to allow programmers to customize exactly as they wish. With large components you're constantly faced with the difficult question - "what might people want to customize?" - there are too many possibilities to cope with at the larger scale.
I also think that GUI components have a long history meaning we've had plenty of time to learn what does and does not work. The same cannot be said of remote objects or distributed systems.
SOA != components; the article "SOA doomed?" does not make clear what is meant by SOA. Spend enough time on the xml-dev or service-orientated-architecture mailing lists and one finds that there seems to be little consensus on what SOA actually *is*, but comparisons to components seems misguided at best.
I tend to favor views espoused by Sean McGrath , which is quite far from comparing SOA to components. It is more focused on message and document exchange than objects and method invocation.
Some good points about components, libraries, and frameworks were made by Ian Bicking [http://blog.ianbicking.org/where-smalltalk-went-wrong-2.html]:
"This is some of what I was referring to when I said that Smalltalk programming styles led to too many frameworks and not enough libraries -- a framework requires you to take on a certain metaphor of execution, to adapt your thought process to the framework instead of adapting the program to your thoughts. Frameworks can be worth it, but they always exact a significant cost."
"I tend to favor views espoused by Sean McGrath , which is quite far from comparing SOA to components. It is more focused on message and document exchange than objects and method invocation."
So here's what I don't get - what processes these messages or documents? What generates a message in the first place? And do those things not need some common understanding of the data they exchange at some level? After all, if there were no agreement, very little processing could happen.
So we appear to have an agreed format for our message and we have to have something that can process that message. That seems like a similar concept to interface and component. Different things apparently, but you've got a chunk of implementation with an agreed contract in either case haven't you?
So it seems that it's still legitimate to talk about a component and an interface - they're just expressed in different ways at implementation level. Thus I can use component and interface in abstract terms to mean either recipient and message or the more familiar OO concepts.
Lastly, I'm familiar with Sean McGrath's views and plenty of people subscribe to them but there are also a large number of businesses and analysts who don't and still talk about components, reuse and interfaces in the same breath as SOA. Regardless, when I look at the issues in the abstract I see no advantage regardless of any particular definition of SOA.
It's likely best to ignore the terms used and concentrate more on the supposed benefits and the means by which they will be realized (gluing together of systems etc).
After working with webframeworks for a while I could not agree more, when building the third version of our in-house CMS, I'm adopting a loosely coupled model with an array of helpers and utlity libraries instead of generalizing, which as you said only leads to ugly hacks when the client needs something "a bit different" something that isn't a rarity in real-world work.
Challenge by Michael Link on February 20, 21:50
Jack Greenfield's book "Software Factories" discusses the topic very thoroughly. It explains why reusable high-level business components didn't show up until now and how this might become reality in the future.
I recommend it for reading, even if it's written by Microsofties :-)
This is such an ivory tower topic. If only the hours burned thinking about it were spent more productivly. Let me burn some more human capital. It would be super if all businesses where the same ivory pile. At the risk of adding context to the dicussion (don't we all fear the nastiness of reality), every businesses has its own set of rules. Many of these rules are dictated by the industry in which they operate. For example, taxes on food in state A is taxed at 3% while state B has no tax, and state C has 10% tax on blue items and 5% on other items. Messy, but not insurmountable. Other rules are really whims such as, well, you already know them. " Give me a component", you rightly demand. "I shall add water so that it might grow".
Usefull components that plug into your systems are called products. You buy them because they are worth it. Your company may develop their own components that encompass your own business whims/requirements. Those components might well be built off sub-components. A sub-what?
An analogy. A mobile home is a housing solution (component) that you buy (to support your PGA adventure). A 2x4 is a comodity product your IT department uses to deliver sea changing solutions over budget.
I think RoR sees its component more as 2x4 rather than sleek Mobile Homes. Don't dimiss the 2x4. It represents an incredible amount of value add and is quite flexible in its use. In the case of RoR, the unit test ensure a luster (and straightness) to be desired.
Please allow me to get carried away with dimessional lumber. My brother, for instance, has mucho $$$ in his basement so that he can make his own 2x4. It is a sight to see. The cost for him to produce a 2x4 is a sight to fear. For him, 2x4 is a hobby. For a business, however, the stakes are a bit different.
Embrace the 2x4. Love it. Beware of splinters. Excuse the intergection of reality.
I'm going to throw in my two cents having spent many years working in different industries as a Software Architect.
Technically there is nothing against producing high-level reusable business components, and it should be encouraged where possible. However in reality it tends to come unstuck way before the programmers get their hands on making the code, and essentially boils down to lack of business process modeling, documentation of business logic and lack of coordinating across the business.
In most companies, their IT infrastructure grew organically from the bottom up without much planning. This meant that you have a mess of systems in different business units that essentially do the same thing, use similar business logic but in a slightly different way. It takes a very good business analyst to knock heads together and separate the wheat from the chaff, to boil the business process down to its core essence, from which a common business component can be built.
And in most cases its near impossible due to the politics of dealing with multiple business units, and so you end up with compromises, which produce components that have workarounds and fast become usable for anything else.
For this reason a good Business Analyst who can stop this from happening is worth his/her weight in gold ;), and that the companies that realize that they really need to start modeling their business process down its essence, will be the ones that thrive in the future.
Hi!
A good 6 months back I discovered Rails, and blogged that 'here was yet another webframework, but I'll have a look at it anyway' and 'looks like it might be good for small stuff, but can it scale?'. At the time you wrote a rather defensive comment in reaction to my rather tactless wording. I didn't understand why you were so vehement, but having read some of the negative comments that have been directed in your direction, I now appreciate your response.
I tried to keep my comments questioning, but these people just seem to lay it on thick without ever learning Ruby. They aren't even 'spiking' to use XP parlance.
I guess it must be a FUD thing.
I'm a Java guy who's been looking for ways to lighten the typical Java enterprise development stacks. Naturally, I eventually made my way to Rails. I completely understand where David Geary is coming from. You should meet him. Very nice and bright guy. (I don't see much offensive in his blog...sorry you took it that way.) I've seen a lot of frameworks like RoR on the surface. There are many frameworks like RoR that don't live up to the promise. They make 80% of the application only 20% as hard, and 20% of the problem 80 times harder.
Being a persistence framework expert, I also understand the criticism of active record. True, Active Record can handle the basic cases, but you don't have to get very far to start to get into edge cases that would make Active Record very difficult to manage. I also think that Tapestry is near brilliant, and is probably better for layered dynamic designs.
But you just don't need Hibernate and Tapestry for most of the jobs that we use them for. For that reason, I think Rails is the bomb. If you play your cards right, you may well have built the killer app that breaks Ruby into the corporate main stream. World domination indeed. You've got another convert. Drop me an e-mail some time. I'd love to talk about how I can help with RoR.
