Scott Bellware [MVP]

SetUp and Teardown Methods in Test Classes

ScottBellware — Sat, 22 Sep 2007 03:39:00 GMT

Jim Newkirk is blogging about the down side of setup and teardown methods in test classes, and why you shouldn't use them.

Setup and teardown methods attract entropy faster than an outsource programmer with his first patterns book.

Jim's new framework, xUnit.NET doesn't have primitives for setup and teardown, although it sounds like there are mechanisms that could be used to accomplish the same kind of thing.

Roy feels that xUnit.NET isn't quite there yet. I think that Roy's perspective will be reflected by lots of folks who have become used to NUnit (et al) over the past six years.

I think that Jim is on the right track, but I'm the kind of guy that feels that a test class's greatest responsibility is to document behavior in the clearest possible way, even if that means sacrificing design qualities best reserved for functional code - like reuse.

Unit test patterns in .NET can learn a lot from RSpec, where setup and teardown methods, as well as test methods themselves, are kept small - tiny, actually - by breaking up multiple test classes into smaller, more focused modules.

An RSpec context ("Describe" block) doesn't have a direct equivalent in .NET and NUnit, but the spirit of a test context can still be achieved.

A context is typically smaller than an xUnit test class. Because it's smaller, it avoids a significant contributor to test class entropy.

Here are a couple practices that I use in RSpec to keep entropy at bay that are also applicable to unit testing practices in .NET:

Don't put anything in a setup method that doesn't pertain to every test method in the test class
If you have stuff in a setup method that doesn't pertain to each test method, break up the test class into multiple test classes where the instance members initialized in the setup pertain to each test method in the new test classes.
These new, smaller test classes are test "contexts".
Keep related contexts in the same file.
When you get four or five test methods in a single context, consider whether the test methods are related to the same concern. If they're not, break up the context.
Name contexts for the concern.
Name test methods to describe the experience of the concern under test, not the implementation of either the test or the functional code.
If you can't see the setup method on the same screen and in the same glance as the test methods, break up the context.

The problem with setup methods has to do with solubility.

Loading setup methods up with initialization that doesn't pertain to each test method and having test classes the scroll on out of sight saps solubility.

If you really want setup behavior in xUnit.NET, I bet you can figure out a way to make that happen. However, Jim and Brad are giving you a chance to reconsider your own testing practices in light of their extensive experience, and in light of emerging beliefs about unit testing and test-driven practices as they continue to evolve based on the discoveries of some of the field's most persistent explorers.

SOA, BI, Events, and Push

ScottBellware — Fri, 21 Sep 2007 16:27:00 GMT

Arnon talks about event-based BI:
http://www.infoq.com/articles/BI-and-SOA

This is exactly what I've been thinking about for our Rails / .NET integrated solution. I thought that this architecture would be received as heresy. I'm stoked to see that folks like Arnon are out in front (of my efforts at least) blazing a path.

My Credo

ScottBellware — Wed, 12 Sep 2007 06:46:00 GMT

I never believe that anything I do is correct until I subject it to the to inquiry, "How is this wrong?"

I believe that everything I do is suspect. This is my point of departure for every single line of code I write. Over the past few years this inquiry has become instinctual.

Write Specs to the Experience Rather than the Implementation

ScottBellware — Mon, 10 Sep 2007 02:29:00 GMT

This post is a place-holder for a longer post with examples, but I've been sitting on this one for months, so I thought I'd just toss it out there for what its worth.

Unit testing practices often make no bones with writing test names that describe the implementation. You see signs of this when programmer-speak shows up in test names. More egregious words like "returns" and "calls" and "invokes" and "raises" and "throws" litter the test names. In more subtle cases, the test names describe the code in the test method itself.

Behavior-driven test names, or specification names, should describe the experience of the user of the, even if the immediate use is another piece of code.

For example rather than using "...throws an exception" in a test name, you could say, "...is not allowed."

You might think that this will lead to tests that are less discoverable, but it doesn't work out that way in practice. When I follow stick to good test code practices and patterns all around, I end up with code that is as discoverable, and often more discoverable than if I tired to capture in the test name that which is already in the test code.

This means having a single concern per test. This often equates to having one assert per test, but the one assert per test rule is a poor choice of language that doesn't express the essence of the problem directly, and depends on the programmer to already know what the rule is rather than rely on how the rule is commonly expressed by those who already know it instinctively (a common problem in agile development).

It also means keeping setup code focused on a single concern and not using too many mocks. And it means a whole lot of stuff that is probably too subtle to describe than it is to demonstrate in code.

TDD is About Not Knowing

ScottBellware — Mon, 10 Sep 2007 00:32:00 GMT

The greatest obstruction to grokking Test-Driven Development is the assertion that a developer makes to himself about how right his plans are for a solution.

The essence of TDD is a suspension of our belief that we know what we're doing, and a submission to a structured process of exploration and elaboration of ideas.

No matter how certain I am that a conception of a design is right, I test the assumption against reality through TDD. I inevitably find that the higher level of my design ideas withstand TDD scrutiny, but the fine-grained atomic design assumptions don't pass muster with any great regularity.

Because of this, I rarely even try to conceive of low level design ideas up front. I know that by fleshing them out though a process of specification with code that I end up with a good result in good time, and the result is frequently better than what I had assumed, and often in surprising ways that open me up to new avenues of learning and understanding in programming and design.

Most good developers refute TDD's viability, and yet many excellent developers practice it diligently, and claim that they went from being good to excellent because of what they learned with TDD.

I think that the difference between a good developer and an excellent developer is the excellent developer's willingness to not know, an openness to explore, and faith in skills that guide solutions to good ends even when the end is not known at the outset.

Agile Doesn't Have the Answers

ScottBellware — Mon, 10 Sep 2007 00:03:00 GMT

Agile doesn't have a One True Answer for software development. Agile gives you a structured way to seek feedback on your on-going exploration.

A predisposition to believe in a One True Answer for anything is one of the worst hindrances to grokking agile development.

Because many methodologies that came before agile were delivered as answers to problems rather than means to effective explore problems - including the methodology itself - folks are still getting hung up on out-dated habits that themselves act as obstructions to agile development's essence.

Agile development isn't a "solution" to anything unless it's done in a way that encourages exploration and has a strong focus on harvesting feedback.

When I hear folks say, "...and so we turned to agile because we thought it could solve our problems," I hear the predispositions of a generation of methodologies that were sold as solutions rather than as inquisitions.

Agile will show you more problems than you ever thought you had before you start to see some progress against these problems. And that progress will come from your open exploration of the truth of your problems rather than from a cork board with index cards, ten-minute daily meetings, and monthly deliveries.

Agile doesn't deliver answers, it only offers you a way to create a safe place to ask hard questions and the permission to try find the answers.

Smurf... er, Scrum

ScottBellware — Sun, 09 Sep 2007 23:32:00 GMT

I started doing something recently that I wish in retrospect hadn't occurred to me, because now I can't stop.

I was at a presentation recently where the speaker used to word "scrum" as a prefix for everything that his team does. At some point it occurred to me that, for some folks, "scrum" had become the System.Object of terms.

This led me to reflect on the only other culture that I knew of that has a universal word: The Smurfs! As soon as this regretful thought crossed my mind, I started subconsciously replacing "scrum" with "smurf" every time I heard the word.

Smurf Room. Daily Smurf. Smurf Planning. Etc, etc, etc. And unfortunately, I find myself snickering now when I hear someone talking about scrum for the absurdity of it all. Kinda like imagining your audience in their underwear.

So, if you and I are ever having a conversation about scrum and I start snickering, please don't assume that I'm laughing at you for your interest in scrum... I'm just having an inner moment of smurfrette's disorder.

Yesterday's Agile

ScottBellware — Mon, 03 Sep 2007 04:16:00 GMT

Been thinking about what's next for agile development...

TDD is still young, but not as young as it was. BDD is creating greater artifact, process, and team unification opportunities for test-first programming in an agile process. Some of tomorrow's practices are already starting to appear, but there's a possibility, as is usual with all things human, that today's agile activists can either be tomorrow's agile activists or tomorrow's agile friction.

Agile development has only had one generation of progress. If the second generation is just around the corner, then today's agilists' identification with the practices that they are known for may be the very weight that slows the transition.

The transition to the second generation of paradigms of any old thing in any old lifetime is a difficult transition. The transition to a second generation paradigm is the event that brings people face to face with the impermanence of the ways and means that they may have likely become identified with in the first and only generation. Getting to tomorrow's agile will be as much or more of a process of letting go as it will be a process of acquiring additional - sometimes historically contradictory - knowledge and practices.

So, will today's TDD celebrities in the .NET world be able to let go of the practice that has become a big part of their identities and move forward with an eye toward progressiveness as they did in 2001 when NUnit started many journeys into unit testing, TDD, and greater agile?

What will tomorrow's agile practices be? Will we have the energy to move forward with verve and vigor as we did back in the day?

Monorail vs. Rails Isn't a Meaningful Question

ScottBellware — Wed, 08 Aug 2007 01:55:00 GMT

Monorail vs. Rails doesn't seem like much of an interesting question. In our work recently at Dovetail, we found that a much more interesting question is something like, "Should we be building forms-over-data web apps on .NET?"

If I have to build a web app on .NET, I'd use Monorail... but I'm beginning to see the use of .NET for most web apps along the lines of the proverbial use of a bazooka to swat mosquitoes. I can see a possible (or likely) future, where I will not ordinarily choose to use .NET to build a web app unless I was forced to do so... assuming that .NET isn't significantly overhauled at some point.

If you've gotta build a web app on .NET, then Monorail and the Castle Project is could very well be your project's saving grace, and you should really consider trying it out before you build another web app on "raw" ASP .NET and webforms.

From my perspective now, Monorail is to ASP .NET as ReSharper is to Visual Studio. Without Monorail, ASP .NET seems a bit primitive, incomplete, and not just a little odd considering how hard ASP .NET as a web app framework tries to pretend that it's not a framework for building apps on the web. Before VB, folks were built business apps using C++. If ASP .NET remains fixated on its current course, I wouldn't be surprised if ASP .NET will be to Rails as C++ became to VB. My own experience of Rails points to .NET being overkill for most of what we need to build most web apps.

Here's a question that I've been floating in my community lately: "What assumptions lead you to believe that .NET is the right framework to build web apps on?" One of the more common answers can be boiled down to something like, "Because we made a lot architectural decisions up front that we can't correct now, and because of this the mosquitoes we're swatting are now as big as elephants... which are more effectively swatted with a bazooka."

So, if you're building web apps on .NET, what leads you to assume that you shouldn't be building on Monorail? And even more fundamentally, if you're building web apps on .NET, what leads you to assume that you should be building on .NET?

There are reasons for either of the three choices, but we technologists often fail to actually make a choice as much as we choose not to choose for not being even aware of our choices. How do you know that you're using the best, most productive tools?

Accountability: Behavior-Driven Development's Other Leg

ScottBellware — Tue, 07 Aug 2007 07:23:00 GMT

Accountability is a huge part of agile development. Behavior-Driven Development (BDD) drives accountability deep into development by having developers maintain the language of the business through the continuum of development process artifacts from user stories, through specifications, and into the application code.

BDD tools support accountability by surfacing specification documents from the executable descriptions of the application that developers have incrementally created through the plain-old Test-Driven Development process with a BDD framework like RSpec.

Stakeholders rarely get a glimpse into the stuff that developers are doing until shippable functionality is shipped, at which point, the software speaks for itself. But simply having working software in-hand isn't always enough, if it were, the drive for ever better acceptance testing tools and practices wouldn't exist.

Part of our accountability to stakeholders rests in proving that we implemented what they assumed we would implement, and that we understood their requirements in the same way that they understand them.

In BDD, developers engage customers in a feedback dialog in the language of the business. A customer would say, "I want you to implement X in such-and-such a way," and the developer replies, "I understood that you're asking me to implement X in such-and-such a way." This is partly what it means to say that a story is a placeholder for a conversation.

Using a BDD framework, developers write executable versions of the customer's user stories and the acceptance criteria of those stories, and does so using plain business language. If the customer were to read the executable specifications that were written by the developer, he should recognize the requirements that he laid out.

The BDD specifications become part of the feedback dialog, except that they do so in the form of a report that is generated from them specification code rather than from a conversation. The report doesn't replace conversations, but it does support the dialog and it gives concrete testimony to the developer's understanding of the requirements at the time that he implemented them.

A stakeholder can read the specification document and gain the confidence that the developer understood the requirements, or that he misunderstood them. As long as the developer strives for an ability to capture the specifications in clear and sensible language, a stakeholder will recognize his business behaviors and processes in the spec doc.

Subsequently, when the developers discipline themselves to write executable specifications in the language of the business, they are caused to think through the wording of a specification and this causes them to be constantly immersed in the consideration of the domain and the domain language. Class libraries and API's that emerge from this kind of consideration typically have a much greater affinity to the business domain that the application serves, and this is also a form of accountability.

By ensuring that the application code respects the domain language, the application code is more recognizable and thus easier to understand, which makes it easier to learn and easier to change and to maintain. Keeping the software code true to the domain is a critical part of an application's resilience to change and resistance to rot. From a BDD perspective, respecting the domain language is as fundamental a design principal as testability.

BDD instills a 360 degree accountability feedback loop. Stakeholders write stories; they add acceptance criteria to the stories; developers talk to stakeholders to understand to business of the story and to get an earful of the domain language; developers capture the acceptance criteria in domain language as executable specifications using a BDD tool; developers implement the application code using practices and patterns like Domain-Driven Design that further respect and enforce the domain language; stakeholders are given access to a report that is generated from the executable specifications that are themselves based on the domain model, and this report is used to vet the developer's understanding of what was to be built.

A specification document is a developer's way of saying, "I heard you ask me for this, and this is what I built (handing the user the spec document). Have I correctly advocated your needs to the software?"

The spec document along with working software to play with as well as some form of customer acceptance test give the customer a tremendous amount of confidence that the developers are building the right thing, and that communication between customer and developer is unfettered. This feedback also helps the developer to built better and more accurate abstractions, and doing so through the plain-old Test-Driven Development processes helps him build the right thing in the right way according to solid design principals.

Through BDD stakeholders and developers work to remain accountable to each other for the clarity of communication that ensures successful product development.

Is this What it Means to be an MVP?

ScottBellware — Wed, 18 Jul 2007 06:58:00 GMT

John commented:

Dude, if you're going to continue to take potshots at MS every chance you get, why do you want to be a *Microsoft* Valued Professional? You're not valuable to them at all at this point. It's like a BMW dealership hiring someone that wants to talk about Mercedes all of the time.

Is this really what folks see as the role of MVP's? If this is indeed the role that the MVP program expects me to play, then there has been some miscommunication, and I would indeed be bound to return the award on principle.

By point:

if you're going to continue to take potshots at MS every chance you get, why do you want to be a *Microsoft* Valued Professional?

I appreciate having been awarded as an MVP for the past four years. I work hard to not end up wanting to be an MVP. I accept the award for the reasons that I was told that I was given the award, but I don't pander after it, and I don't retrofit my principles with convenient Redmond-sized loopholes to ensure that I continue to receive it. MVP's aren't supposed to be talking heads. We're supposed to be independent. In fact, independence is part of our charter as I understand it, and as it's expressed by the moto, "Independent experts. Real world answers."

You're not valuable to them at all at this point

If dissent is not valuable, and of my dedication to an almost unending effort in community facilitation in my region and abroad isn't valuable, then you might be right.

It's like a BMW dealership hiring someone that wants to talk about Mercedes all of the time

Does the public really believe that MVP's are supposed to toe the line and be on-message as Microsoft employees are? Is an MVP measured by his or her willingness to merely pretend to be an independent expert and yet remain on call to wax favorably about Microsoft whenever it serves Microsoft's agenda?

This is really distressing. This image of the MVP program is about as satisfying as infotainment when you're hankering for journalism.

The definition of an MVP from the MVP site on the Microsoft support website says, "Microsoft Most Valuable Professionals (MVPs) are exceptional technical community leaders from around the world who are awarded for voluntarily sharing their high quality, real world expertise in offline and online technical communities. Microsoft MVPs are a highly select group of experts that represents the technical community's best and brightest, and they share a deep commitment to community and a willingness to help others."

If this is no longer applicable, I'd really appreciate if someone from the MVP program would ping me and let me know, because the MVP program that I feel honored to be a part of is the one that stands by this credo, not one whose consent can be bought for the mere price of an MSDN subscription and four nights of lodgings is Seattle every year.

I've been a Microsoft Most Valuable Professional since January of 2004. I will remain a Microsoft Most Valuable Professional for as long as the Microsoft support divisions sees fit to give me the award... or until the MVP program transforms in fact into the perverted army of shills that John apparently believes it ought to be.

Are Rails' Model Objects "View Model Objects"? (and some questions about non-generic subdomains)

ScottBellware — Tue, 17 Jul 2007 05:06:00 GMT

Should we assume that the model objects that we build and use in user interfaces to be reusable in other application layers and services?

I'm still chewing on the idea of Ruby on Rails as a web front end to a clean data model where the heavy-lifting, enterprisey part of the app is written on .NET or J2EE.

I'm looking at Ruby on Rails as the Visual Basic 6 of the 21st century. It's a means for the Mort persona to get data out of forms and into a local application database that is modeled to fit the needs of the application's user interaction services, like a web UI for example.

From this perspective, the Rails's model objects are primarily a model layer used for the UI. They're not exactly a presentation model (thanks for the clarification, Jeremy... by the way, due to the high quality technical support you provide, I've decided to sell your cell phone number to the highest bidder on eBay :), and they may not be a generically reusable model. In fact, I'm really wondering if it's truly possible to create a model that can be meaningfully-reused within architectural partitions of the same logical application. And if that's the case, then a light-weight model that does a really great job of specifically serving the UI might very well be a really good thing.

A couple of folks commented that using Rails would mean maintaining the same business rules on two platforms. I'm not sure sure that I'm convinced that this is the case in practice.

Rails' DSL for model object business rules is awfully good for user interaction services validation, and this is what makes me think of Rails model objects as view (UI) model objects. Creating Rails' model objects and business rules is really trivial. Yes, I know that I'm suggesting something that might violate DRY if the user interaction model rules intersect with the rules for the same entities as implemented on another platform and used in other contexts, but I'm not convinced that this intersection is sufficiently large (in all cases) to worry about it.

Model objects have different rules for different contexts. The rules applied to the UI might not be the same rules applied to asynchronous event processing and out-of-process, high-yield services. If they're not, and if I'm set on using the same type library in both parts of the architecture, then I need a way to configure the rules at run time, which means that I need a rules framework and a configuration schema so that I can vary the behavior of instances of the same types used in orthogonal contexts.

On the other hand, I could simply build a non-generic subdomain for the specific needs of the specific representations of the model in specific architectural partitions. I mean, it's not hard to generate some model objects to represent a clean data model. That's certainly true for Rails ActiveRecord and quite true for Castle ActiveRecord as well.

Yikes! What if the data model elements used in the UI aren't even the same elements that I need in the enterprisey partitions? If I choose to reuse a C# domain model in the UI and in the enterprisey stuff, am I doing the right thing? I may just be pushing round pegs into square holes (yes, I'm deliberately inverting this metaphor). If the data models are different, and if the business rules are different, should I be using a generic domain model?

And what if the needs of one part of the app change? Do I run different versions of the same types in different parts of the architecture so that I can achieve my .NET domain model assembly reuse goals? Is this the right set of design pressures to yield to?

What if Rails' model objects are really just view model objects? If they are, I can start to treat Rails the way I treated Visual Basic and Visual FoxPro... I can treat it as RAD... but a more evolved RAD... a RAD for a subsequent era of software maturity.

In a software ecosystem that includes Rails, it's just a tool to get data from HTML forms into an application database, to do so with a dead-simple programming model, and with assumptions of responsible, partitioned architecture, with lots of good AJAX interactivity and asynchronicity, and with a declaritive description language that I believe suits the objectives and responsibilities of the Real Mort.

Considering Ruby on Rails and Interop: Developer Skills

ScottBellware — Mon, 16 Jul 2007 05:06:00 GMT

We sell an enterprise product, and that product is customized by our customers. More precisely, our product is customized by day coders.

If I put Monorail and Windsor in their hands and tell them to go forth and code IoC and ORM with NHibernate after giving them some guidance and training, will they be enabled or mortified.

I think that ASP .NET Web Forms are more complicated than they need be and that Monorail does a good job of simplifying web application development, and that it does all the right things for me. I'm sometimes concerned about how effectively we will be able to transfer that knowledge to our customers' developers.

I don't think that falling back to ASP .NET Web Forms is the right thing. Monorail's got the right stuff. But does Ruby on Rails have righter stuff?

There's no shortage of books on Rails and there are implementation and training partners. Over simple data models, and clean UI's built for well-designed task flows, Rails might very well be easier for day coders to grok. I don't know if that's categorically true, and it will depend quite a bit on the complexity of the model Rails' data fetching approach which I haven't looked too deeply into.

Then again, I might be underestimating our customer's staff. Maybe they will grok IoC and NHiberate sufficiently. And then again, maybe I shouldn't require them too.

Monorail has been a great framework to work with so far, and we haven't even scratched the surface yet. But dammit, it should be a lot easier than it is to move data from a form to a database, and do it in a way that's easily testable. I can get the testability from Ruby without the IoC, but Rails isn't NHibernate.

So... do I need NHibernate? Can I design a model that simplifies storage and representation sufficiently so that it isn't obligatory?

If I can make the model simple enough so that I can leverage Rails, I can build the parts of the app that need to be easily customized in what might very well be a simpler set of tools. It's possible that my team might get their work on the UI done faster and that we can spend more time on parts of the app that aren't customizable, are more complex, and that deliver a significant chunk of our value proposition.

I'm not saying that the UI is a trivial piece of the system, but the .NET stuff in the backend that will indeed make use of Windsor and more than likely will make use of NHibernate is some serious business. I'd like to simplify the front end if I can - even simpler than Monorail - if that's possible.

I'm debating with myself here. I'd be very interested to hear from folks who've built non-trivial stuff in Rails. I'd especially like to understand more about their architectural choices.

Considering Ruby on Rails and Interop: Model Code and Data Access

ScottBellware — Mon, 16 Jul 2007 03:43:00 GMT

I'm concerned that if I build my application's front end on Ruby on Rails that I'll end up needing to create and maintain yet another model layer and data access layer for the parts of the application that don't run in the web process, like out-of-process event processing services, for example.

The developer in me wants to use the NHibernate layer that I'm familiar with rather than use ActiveRecord in the UI and NHibernate in the rest of the app. The C# model classes I create can ostensibly be re-used and shared between the web app and other parts of the app that aren't the web app. If I use Rails, I'll have a model coded in Ruby and a model coded in C#. These models will require mapping to the database and I'll need to test and maintain both of those going forward.

I'm wondering if my assertions about using the model classes in other parts of the application - parts that aren't part of the web app - is an unfounded assumption rather than a foregone conclusion.

What if the model that I use in a web UI isn't a sufficiently generic subdomain that it can be reused.

I do data access through the model code in concert with NHibernate. What if the data access needs of parts of the app outside of the web UI aren't the same as the web UI's needs. I wouldn't get the reuse that I'm assuming I can. I might force my web app's model and data access into an event processing service, for example, but would it be the right thing to do?

If I reuse the same model and data access code in parts of apps that represent orthogonal concerns, will I be bringing over business rules that don't make sense or aren't applicable to all of those concerns? If so, would an ActiveRecord model suffice for the web app. Moreover, would it better serve the web app, and more yet, would it better serve the developers of the web app, and the developers at or customers' sites that customize the app?

The overall question that I'm driving at here is whether Rails is a good enough front end for an app and whether my presumptions and prejudice about model code reuse are keeping me from making use of a simpler, more developer-friendly framework for forms over data.

Considering Ruby on Rails and Interop: Transactions

ScottBellware — Sun, 15 Jul 2007 18:10:00 GMT

My usual reason for outright dismissing an app with a Rails front end centers on System.Transactions ability to continue a distributed transaction that was started in a web app process into a workflow. Since WF supports System.Transactions through compensating activities, I don't want to give up the ability to issue a rollback on a transaction and have that carry through anything done with a workflow.

The problem with the last sentence is the word "anything". It's so damned vague that its meaningless from a tangible design perspective.

One of our customers could put literally anything into play when our application executes a workflow hook at significant state changes coded into the app. I can't really guarantee that anything put into play in a workflow can support a rollback, or even if it would be sensible to make it support atomic transactions.

I literally can't think of anything that we're using workflow for that doesn't require a more robust compensation mechanism than a System.Transactions rollback. In fact, the scenarios that I'm aware of the require compensation also require user intervention. This means that the compensation task flows also require user interfaces, which in turn means that compensation would probably be better served as entirely different use cases with different workflows.

I don't have a lot of confidence that I need to or even should support using distributed transactions in customer-customizable workflows where that transaction is managed in an execution context that is intended to be synchronous and API-oriented rather the asynchronous and message-oriented.

Distributed transactions don't seem like a good reason to dismiss Rails as a web front end.